Por que precisamos montar no Linux?

67

Entendo o que é a montagem no Linux e os arquivos do dispositivo. No entanto, eu não entendo POR QUE precisamos montar.

Por exemplo, conforme explicado na resposta aceita desta pergunta , usando este comando:

mount /dev/cdrom /media/cdrom

estamos montando o dispositivo CDROM /media/cdrome, eventualmente, conseguimos acessar os arquivos do CDROM com o seguinte comando

ls /media/cdrom

que listará o conteúdo do CD-ROM.

Por que não pular a montagem completamente e faça o seguinte?

ls /dev/cdrom

E tenha o conteúdo do CDROM listado. Espero que uma das respostas seja: " É assim que o Linux é projetado ". Mas se sim, então por que foi projetado dessa maneira? Por que não acessar o /dev/cdromdiretório diretamente? Qual é o verdadeiro objetivo da montagem?

Greeso
fonte
2
Você também pode estar interessado em problemas com a compreensão do conceito de montagem
PM 2Ring
23
Observe praticamente todos os sistemas operacionais "mount". É transparente na maioria dos casos. Quando no Windows você escolhe "remover com segurança" para um pendrive, na verdade você está executando uma quantidade, depois que ele foi montado automaticamente pelo sistema. O Linux simplesmente não isola o usuário tão longe do processo, portanto, como resultado, você pode 'personalizá-lo' mais - digamos, a partição umsdos não difere de maneira visível do vfat, mas se você usá mount -t umsdos-lo, você tem todas as permissões, propriedades, arquivos especiais, fifos etc. do Linux. Se você mount -t vfatse comportar como uma partição simples do Windows.
SF.
7
"Entendo o que é montagem no linux, e entendo os arquivos do dispositivo." Aparentemente não;)
Lightness Races com Monica
5
Why not access the /dev/cdrom directory directly?Porque não é um diretório.
Brandon

Respostas:

67

Uma razão é que o acesso no nível do bloco é um nível um pouco menor do que lsseria capaz de trabalhar. /dev/cdrom, ou dev/sda1pode ser sua unidade de CD-ROM e partição 1 do seu disco rígido, respectivamente, mas eles não estão implementando a ISO 9660 / ext4 - são apenas indicadores RAW para os dispositivos conhecidos como Arquivos de dispositivo .

Uma das coisas que a montagem determina é COMO usar esse acesso bruto - quais módulos de lógica / driver / kernel do sistema de arquivos vão gerenciar as leituras / gravações ou traduzir ls /mnt/cdromem quais blocos precisam ser lidos e como interpretar o conteúdo desses bloqueia em coisas como file.txt.

Outras vezes, esse acesso de baixo nível pode ser bom o suficiente; Acabei de ler e escrever em portas seriais, dispositivos USB, terminais tty e outros dispositivos relativamente simples. Eu nunca tentaria ler / gravar manualmente em / dev / sda1 para, digamos, editar um arquivo de texto, porque eu basicamente teria que reimplementar a lógica ext4, que pode incluir, entre outras coisas: procure os inodes de arquivos, encontre o blocos de armazenamento, leia o bloco completo, faça minhas alterações, escreva os blocos completos e atualize o inode (talvez) ou, em vez disso, escreva tudo isso no diário - muito difícil.

Uma maneira de ver isso por si mesmo é apenas tentar:

[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory

/devé um diretório e você pode cde lstudo o que quiser. /dev/sda1não é um diretório; é um tipo especial de arquivo que o kernel oferece como um 'identificador' para esse dispositivo.

Veja a entrada da wikipedia em Arquivos de dispositivos para um tratamento mais detalhado.

Ehryk
fonte
4
Estou encobrindo alguns detalhes, porque acho que coisas ruins acontecerão se você começar a gravar em qualquer dado armazenado em / dev / sda1 e, portanto, presumo que haja algumas medidas preventivas ou abstração que impediriam você de sobrescrever as coisas. Mas, resumindo, se você soubesse exatamente como e onde gravar no disco, poderia fazê-lo manualmente /dev/sda1. Observe que algumas ferramentas interagem diretamente com discos brutos, como swapon/swapoffe dd.
Ehryk
4
Só para adicionar um pouco mais, a montagem inicializa o sistema de arquivos e, portanto, também ativa toda uma camada de manipulação automática de operações de entrada / saída que é transparente para o usuário (como armazenar em cache arquivos na RAM, enfileirar as operações, manter os estados dos arquivos abertos e assim por diante). É por isso que você também precisa desmontar o sistema de arquivos corretamente para evitar corrupção (ou pelo menos sincronizá-lo). A montagem está presente em todas as plataformas mais usadas, não apenas no Linux. Se a montagem é gerenciada automaticamente pelo ambiente de área de trabalho (KDE ou gnome), ela fica tão oculta quanto no Windows MS.
orion
6
@Ehryk (3 comentários) a única medida preventiva em um sistema Linux típico são as permissões do sistema de arquivos - em outras palavras, você precisa usar a conta root para gravar em um arquivo de dispositivo. Se você fizer isso, poderá fazer o que quiser cat >/dev/sda1e o Linux não irá impedi-lo. (Escusado será dizer, isso seria completamente corromper o sistema de arquivos.)
David Z
5
@psusi Você não podia fazer isso no Windows 95, é verdade. Mas estava presente (e bem oculto) no MS DOS e Windows NT. Seu Windows moderno baseado em NT certamente permite que você monte e desmonte partições à vontade (mesmo em pastas de outras partições e até várias pastas ao mesmo tempo) - normalmente apenas monta todas as partições desconhecidas para gerar letras por padrão. Você também pode acessar o dispositivo sem montá-lo usando o caminho completo (muito parecido com o modo unix), mas apenas se não estiver bloqueado - o que é claro se estiver montado no momento.
Luaan 8/01/15
3
@Luaan & psusi A Psusi tem o direito de fazê-lo. Mas, para quase todas as intenções e propósitos, o efeito do chamador da API do Win32 é basicamente idêntico. (Para conformidade com o Posix, existe até uma emulação de semântica de montagem.) O Win9x realmente tem o conceito de montagem porque ainda é executado no DOS. O suporte ao FAT foi incorporado ao DOS como um manipulador nativo, semelhante à maneira como o kernel do NT lida com ele. Mas o CDROM e os sistemas de arquivos de rede precisavam ser montados. (Lembre-se do MSCDEX for CD. Isso forneceu o manipulador do sistema de arquivos ISO / RockRidge e o montou na letra da unidade).
Tonny
20

Basicamente, e para simplificar, o sistema operacional precisa saber como acessar os arquivos nesse dispositivo.

mount não é apenas "dar acesso aos arquivos", mas também informar ao sistema operacional o sistema de arquivos da unidade, se for somente leitura ou acesso de leitura / gravação, etc.

/dev/cdromé um dispositivo de baixo nível, as funções do sistema operacional não saberiam como acessá-los ... imagine que você coloque um cdrom com formato estranho (até mesmo um CD de áudio), como lssaber quais arquivos (se houver) estão disponíveis? o cd-rom sem "montar" primeiro?

Observe que isso acontece automaticamente em muitos sistemas operacionais (mesmo Linux em algumas distribuições e interfaces gráficas), mas isso não significa que outros sistemas operacionais não estejam "montando" as unidades.

Jcl
fonte
8

Para consistência

Imagine que você tem algumas partições no primeiro disco rígido do seu sistema. Por exemplo /dev/sda2,. Mais tarde, você decide que a unidade não é grande o suficiente para comprar uma segunda e adicioná-la ao sistema. De repente, isso se torna /dev/sdae sua unidade atual se torna /dev/sdb. Sua partição é agora /dev/sdb2.

Usando o sistema proposto, você teria que alterar todos os scripts, aplicativos, configurações etc. que acessam os dados na sua partição antiga para refletir essa alteração nos nomes.

No entanto, a montagem permite que você ainda use o mesmo ponto de montagem para esta unidade renomeada. Você precisaria editar /etc/fstabpara informar ao seu sistema que (por exemplo) /media/backupestá agora /dev/sdb2, mas essa é apenas uma edição.

Observe que os sistemas modernos são ainda mais fáceis. Em vez de referenciar o dispositivo como /dev/sda2ou /dev/sdb2, eles têm UUIDS, que parecem semelhantes c5845b43-fe98-499a-bf31-4eccae14261bou podem receber etiquetas mais amigáveis, como as backupque podem ser usadas para referenciar o dispositivo durante a montagem. Dessa forma, o nome do dispositivo não muda ao adicionar um novo dispositivo, o que torna a administração ainda mais simples:

# mount LABEL="backup" /media/backup

Por segurança

Ao exigir que um dispositivo seja montado, o administrador pode controlar o acesso ao dispositivo. O dispositivo pode ser removido quando desmontado, mas não quando estiver em uso (a menos que você queira sofrer perda de dados). Se você é (era) um usuário do Windows, lembre-se do pequeno ícone verde na área de notificação que informa que é seguro remover um pen drive? Isso é o Windows montando e desmontando o suporte para você. Portanto, o princípio não é apenas o Unix / Linux.

garethTheRed
fonte
Os IDs universais são na verdade UUIDs, não os GUIDs da Microsoft.
Ruslan
@Ruslan - então eles são! Eu estava com o MS na época. Muito obrigado - eu mudei.
precisa
6

Eu chamaria isso de razões históricas. Não que as outras respostas estejam erradas, mas há um pouco mais na história.

Compare o Windows: o Windows foi iniciado como um sistema operacional de computador único e usuário único. Esse computador único provavelmente tinha uma unidade de disquete e uma unidade de disco rígido, sem conexão de rede, sem USB, sem nada. (O Windows 3.11 tinha recursos de rede nativos; o Windows 3.1 não .)

O tipo de configuração em que o Windows nasceu era tão simples que não havia necessidade de fantasia: basta montar tudo (todos os dois dispositivos) automaticamente todas as vezes, não há (não) muitas coisas que poderiam dar errado.

Por outro lado, o Unix foi criado para rodar em redes de servidores com vários usuários desde o início.

Uma das decisões de design do Unix foi que o sistema de arquivos deveria aparecer como uma única entidade uniforme para os usuários finais, independentemente de quantos computadores os discos físicos estivessem espalhados, independentemente do tipo de disco e de dezenas de computadores o usuário acessaria a partir de. O caminho lógico para os arquivos do usuário permaneceria o mesmo, mesmo se o local físico desses arquivos tivesse mudado da noite para o dia, por exemplo, devido à manutenção do servidor.

Eles estavam abstraindo o sistema de arquivos lógicos, os caminhos para os arquivos, dos dispositivos físicos que armazenavam esses arquivos. Digamos que o servidor A esteja normalmente hospedando / em casa, mas o servidor A precise de manutenção: basta desmontar o servidor A e montar o servidor de backup B em / home, e ninguém além dos administradores perceberia.
(Diferentemente da convenção do Windows de atribuir nomes diferentes a diferentes dispositivos físicos - C :, D :, etc. - que funcionam contra a transparência que o Unix estava buscando.)

Nesse tipo de cenário, você não pode simplesmente montar tudo à vista, quer ou não,

Em uma rede grande, discos e computadores individuais ficam fora de serviço constantemente. Os administradores precisam dizer o que está montado onde e quando, por exemplo, fazer um desligamento controlado de um computador enquanto outro computador assume de maneira transparente a hospedagem dos mesmos arquivos.

É por isso que, de uma perspectiva histórica: o Windows e o Unix vieram de diferentes origens. Você poderia chamar isso de diferença cultural, se quiser:

  • O Unix nasceu em um ambiente em que o administrador precisava controlar a montagem; das dezenas de dispositivos de armazenamento na rede, o administrador deve decidir o que será montado onde e quando.
  • O Windows nasceu em um ambiente em que não havia administrador e apenas dois dispositivos de armazenamento, e o usuário provavelmente saberia se o arquivo estava no disquete ou no disco rígido.
  • (O Linux nasceu como um sistema operacional de computador único, é claro, mas também foi projetado explicitamente desde o início para imitar o Unix o mais próximo possível de um computador doméstico.)

Mais recentemente, os sistemas operacionais foram se aproximando:

  • O Linux adicionou mais coisas de computador único e usuário único (como montagem automática); como se tornou frequentemente usado em configurações de computador único.
  • O Windows adicionou mais segurança, rede, suporte para vários usuários, etc .; à medida que a rede se tornou mais onipresente e a Microsoft começou a criar um sistema operacional para servidores também.

Mas ainda é fácil dizer que os dois são o resultado de diferentes tradições.

jg-faustus
fonte
11
Não é só isso. Os dispositivos são abstrações de baixo nível para uso dos drivers do sistema de arquivos (e possivelmente de outro software do sistema). O Unix foi projetado para ser um sistema operacional para programadores de sistemas operacionais. Por exemplo, os programadores desses drivers do sistema de arquivos. É por isso que essas abstrações de baixo nível são expostas ao usuário.
Reinierpost
5

Existem várias vantagens no arranjo atual. Eles podem ser agrupados em vantagens de arquivos especiais de bloco e vantagens de pontos de montagem.

Arquivos especiais são arquivos que representam dispositivos. Uma das idéias em que o unix foi construído é tudo um arquivo. Isso simplifica muitas coisas, por exemplo, a interação do usuário é apenas a leitura e gravação de arquivos em um dispositivo tty, que é um arquivo especial de caracteres. Da mesma forma, verificar se há blocos defeituosos, particionar ou formatar um disco são apenas operações de arquivo. Não importa se o disco é mfm, ide, scsi, fiberchanel ou qualquer outra coisa, é apenas um arquivo.

Mas, por outro lado, você pode não querer lidar com o disco inteiro ou particionar apenas os arquivos e, em muitos casos, mais arquivos do que cabem em um disco. Portanto, temos pontos de montagem. Um ponto de montagem permite colocar um disco inteiro (ou partição) em um diretório. Nos meus dias do Slackware, quando um disco rígido de bom tamanho tinha algumas centenas de MB, era comum usar o CD como / usr e o disco rígido para /, / usr / local e swap. Ou você pode colocar / em uma unidade e / casa em outra.

Agora notei que você mencionou montar seu CD em / media / cdrom, o que é útil para computadores com apenas uma unidade de CD-ROM, mas e se você tiver mais de um? onde você deve montar o segundo? ou o terceiro? ou o décimo quinto? você certamente pode usar / media / cdrom2, etc. Ou pode montá-lo em / src / samba / resources / windows-install ou / var / www, ou em qualquer lugar que faça sentido.

hildred
fonte
Acho que OP significava por que não pular o todo mountinteiramente e apenas interagir /dev/cd0, /dev/cd2, /dev/sda1, /dev/sda2diretamente - cada um já possui um tipo de 'diretório' designado.
Ehryk
11
Você está correto, mas você realmente consideraria / dev / sdb9 / share / doc / package / README um bom caminho? até d: / share / doc / package / README é melhor, mas / usr / share / doc / package / README tem semântica! esse é o valor de um ponto de montagem.
Hildred
3
Eu suspeito que o uso semântico veio mais tarde como um subproduto útil da necessidade absoluta de 'colocar algum código entre o sistema de diretório e o ponteiro de arquivo bruto para o dispositivo', porque usar cd / ls / nano / tudo o mais é muito mais fácil do que o raw escreve:, dd if=/file of=/dev/sda2 bs=4096 skip=382765832 count=84756muito menos a atualização de inode / FAT / journal associada.
Ehryk
(alguns masoquistas linux seria provavelmente amor / dev / sdb9 como diretórios de trabalho, tenho certeza)
Ehryk
2
Meu primeiro computador executou cp / m em disquetes de 8 cm. Ele não suportava subdiretórios. Um diretório por disco. Um caminho parecia b: name.ext. A idéia de nomeação semântica já estava estabelecida. Até sistemas de fita nomes de arquivos usados.O UNIX já havia rejeitado a idéia de letras de unidades para pontos de montagem.A propósito, @Ehryk, você sabia que é possível montar uma unidade em um diretório não apenas no Windows, mas em dos? Eu fiz isso no MS-DOS 5 . além disso, quando eu estou procurando uma página de homem que eu não quero ter que lembrar de qual computador ele está em muito menos que dirige.
Hildred
5

O título da pergunta é: Por que precisamos montar no Linux?

Uma maneira de interpretar essa pergunta: Por que precisamos emitir mountcomandos explícitos para disponibilizar sistemas de arquivos no Linux?

A resposta: nós não.

Você não precisa montar sistemas de arquivos explicitamente, pode organizar isso automaticamente, e as distribuições Linux já fazem isso para a maioria dos dispositivos, assim como Windows e Macs.

Então provavelmente não é isso que você queria perguntar.

Uma segunda interpretação: Por que às vezes precisamos emitir mountcomandos explícitos para disponibilizar sistemas de arquivos no Linux? Por que não fazer com que o sistema operacional sempre faça isso por nós e oculte-o do usuário?

Esta é a pergunta que estou lendo no texto da pergunta, quando você pergunta:

Por que não pular a montagem completamente e faça o seguinte

ls /dev/cdrom

e tem o conteúdo do CD-ROM listado?

Presumivelmente, você quer dizer: por que não apenas fazer com que esse comando faça o que

ls /media/cdrom

faz agora?

Bem, nesse caso, /dev/cdromseria uma árvore de diretórios, não um arquivo de dispositivo. Portanto, sua verdadeira pergunta parece ser: por que ter um arquivo de dispositivo em primeiro lugar?

Eu gostaria de adicionar uma resposta às que já foram dadas.

Por que os usuários conseguem ver os arquivos do dispositivo?

Sempre que você usa um CD-ROM ou qualquer outro dispositivo que armazena arquivos, é usado um software que interpreta o que estiver no seu CD-ROM como uma árvore de arquivos. É chamado sempre que você usa lsou qualquer outro tipo de comando ou aplicativo que acesse os arquivos no seu CD-ROM. Esse software é o driver do sistema de arquivos em particular usado para gravar os arquivos no CD-ROM. Sempre que você lista, lê ou grava arquivos em um sistema de arquivos, o trabalho desse software é garantir que as operações de leitura e gravação de baixo nível correspondentes sejam executadas no dispositivo em questão. Sempre que você é mountum sistema de arquivos, você está dizendo ao sistema qual driver do sistema usar para o dispositivo. Se você faz isso explicitamente com ummountcomando, ou deixe que o sistema operacional seja feito automaticamente, ele precisará ser feito e, é claro, o software do driver do sistema de arquivos precisará estar lá em primeiro lugar.

Como um driver de sistema de arquivos faz seu trabalho? A resposta: faz isso lendo e gravando no arquivo do dispositivo. Por quê? A resposta, como você já declarou: O Unix foi projetado dessa maneira. No Unix, os arquivos de dispositivos são a abstração de baixo nível comum para dispositivos. O software realmente específico do dispositivo (o driver do dispositivo) para um dispositivo específico deve implementar a abertura, o fechamento, a leitura e a gravação no dispositivo como operações no arquivo do dispositivo. Dessa forma, o software de nível superior (como um driver do sistema de arquivos) não precisa saber muito sobre o funcionamento interno de dispositivos individuais. Os drivers de dispositivo de baixo nível e os drivers do sistema de arquivos podem ser gravados separadamente, por pessoas diferentes, desde que eles concordem em uma maneira comum de interagir entre si, e é para isso que servem os arquivos do dispositivo.

Portanto, os drivers do sistema de arquivos precisam dos arquivos do dispositivo.

Mas por que nós, usuários comuns, conseguimos ver os arquivos do dispositivo? A resposta é que o Unix foi projetado para ser usado por programadores de sistemas operacionais. Foi projetado para permitir que seus usuários escrevam drivers de dispositivo e drivers de sistema de arquivos. É assim que eles são escritos.

O mesmo se aplica ao Linux: você pode escrever seu próprio driver do sistema de arquivos (ou driver de dispositivo), instalá-lo e usá-lo. Torna o Linux (ou qualquer outra variante do Unix) facilmente extensível (e é de fato a razão pela qual o Linux foi iniciado): quando uma nova peça de hardware entra no mercado, ou uma nova maneira mais inteligente de implementar um sistema de arquivos é projetada. , alguém pode escrever o código para suportá-lo, fazê-lo funcionar e contribuir com o Linux.

Os arquivos do dispositivo facilitam isso.

reinierpost
fonte
11
muito bem explicado
Shailendra
4

Muitos mecanismos de banco de dados podem trabalhar diretamente com discos ou partições brutos. Por exemplo, MySQL:

http://dev.mysql.com/doc/refman/5.7/en/innodb-raw-devices.html

Isso evita a sobrecarga de passar pelos drivers do sistema de arquivos, quando todo o mecanismo de banco de dados realmente precisa é de um arquivo enorme que preenche o disco.

Tom Robinson
fonte
3

Porque /dev/cdromé um dispositivo, enquanto que /media/cdromé um sistema de arquivos . Você precisa montar o primeiro no último para acessar os arquivos no CD-ROM.

Seu sistema operacional já está montando automaticamente os sistemas de arquivos raiz e de usuário a partir do seu dispositivo de disco rígido físico, quando você inicializa o computador. Isso está apenas adicionando mais sistemas de arquivos para usar.

Todos os sistemas operacionais fazem isso - no entanto, alguns (como o Windows, quando ele monta um CD-ROM D:) o fazem de forma transparente. O Linux deixa para você, para que você tenha maior controle sobre o processo.

Corridas de leveza com Monica
fonte
2
Eu tenho que discordar de sua redação. /dev/cdromé um arquivo de dispositivo (que possui habilidades especiais que nos permitem ter uma comunicação de E / S facilmente de / para o dispositivo associado). /media/cdromé um diretório, mas essencialmente é outro arquivo (lembre-se, tudo é um arquivo no Linux, incluindo diretórios). Agora, quando acabamos mounttendo uma capacidade especial de visualizar o conteúdo do arquivo do dispositivo como um sistema de arquivos. Meu entendimento da última frase é da leitura das respostas acima.
Greeso
@Greeso: Eu mantenho a minha resposta.
Lightness Races com Monica
0

Isso ocorre porque há, com muitas mídias para UIs de desktop e laptop, ambiguidade sobre o que fazer quando a mídia é inserida, porque a intuição do usuário é que inserir o disco na caixa física com a qual o usuário interage não é diferente, digamos , inserindo-o em um dispositivo próximo ao computador que possui uma conexão de rede.

Portanto, no sentido fundamental, a interface do usuário para mídia precisa tratar os dois tipos de eventos de montagem em potencial da mesma forma, e não há uma maneira boa para os computadores lidar com montagens de rede da maneira mais intuitiva possível para montagens de rede com outras interfaces de usuário para computadores, como smartphones, tablets e computadores portáteis, sem a possibilidade de inserir mídia física nos dispositivos. (Observe que a interface do iPhone é horrível para a troca de cartões SIM, o único tipo de mídia física que os dispositivos iOS inseriram neles.

Observe também que outras abordagens populares das interfaces de usuário para esse tipo de caixa física (por exemplo, Windows 98, Windows 8, Mac OS X versão 10.2 (Jaguar) e Mac OS X versão 10.9 (Mavericks)) têm os mesmos problemas e use caixas de diálogo adicionais da GUI para resolver a possível confusão (por exemplo, o Windows 8 geralmente é configurado para solicitar a cada novo CD inserido se deve ser montado como um sistema de arquivos, uma mídia de música ou, se apropriado, uma coleção de vídeos MP4 ) Não há razão para que nenhuma dessas caixas de diálogo do usuário possa ser usada com Linux ou outros UNIXes.

Charles Stewart
fonte