Eu entendo o que é montagem no Linux e entendo os arquivos de dispositivos. Porém não entendo POR QUE precisamos montar.
Por exemplo, como explicado noresposta aceita desta pergunta, usando este comando:
mount /dev/cdrom /media/cdrom
estamos montando o dispositivo CDROM /media/cdrome eventualmente podemos acessar os arquivos do CDROM com o seguinte comando
ls /media/cdrom
que listará o conteúdo do CDROM.
Por que não pular totalmente a montagem e fazer 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 forma? Por que não acessar o /dev/cdromdiretório diretamente? Qual é o real propósito da montagem?
Responder1
Um dos motivos é que o acesso em nível de bloco é um pouco mais baixo do que lsseria possível trabalhar. /dev/cdrom, ou dev/sda1pode ser sua unidade de CD ROM e a partição 1 do seu disco rígido, respectivamente, mas eles não estão implementando ISO 9660/ext4 - são apenas ponteiros RAW para os dispositivos conhecidos comoArquivos de dispositivo.
Uma das coisas que o mount determina é COMO usar esse acesso bruto - qual lógica do sistema de arquivos/driver/módulos do kernel gerenciarão as leituras/gravações ou traduzirão ls /mnt/cdromem quais blocos precisam ser lidos e como interpretar o conteúdo desses blocos em coisas como file.txt.
Outras vezes, este acesso de baixo nível pode ser suficiente; Acabei de ler e gravar em portas seriais, dispositivos USB, terminais tty e outros dispositivos relativamente simples. Eu nunca tentaria ler/escrever manualmente de /dev/sda1 para, digamos, editar um arquivo de texto, porque basicamente teria que reimplementar a lógica ext4, que pode incluir, entre outras coisas: procurar os inodes do arquivo, encontrar o blocos de armazenamento, ler o bloco completo, fazer minhas alterações, escrever os blocos completos e, em seguida, atualizar o inode (talvez) ou, em vez disso, escrever tudo isso no diário - muito difícil.
Uma maneira de ver isso por si mesmo é tentar:
[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory
/devé um diretório, e você pode cde lso que quiser. /dev/sda1não é um diretório; é um tipo especial de arquivo que o kernel oferece como um 'identificador' para esse dispositivo.
Vera entrada da Wikipedia em Arquivos de dispositivospara um tratamento mais aprofundado.
Responder2
Basicamente, e para simplificar, o sistema operacional precisa saber como acessar os arquivos daquele dispositivo.
mountnão está apenas "dando acesso aos arquivos", mas também informando ao sistema operacional o sistema de arquivos que a unidade possui, se é 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ê colocou um cdrom estranhamente formatado nele (até mesmo um cd de áudio), como saberia lsquais arquivos (se houver) estão lá? o CD-ROM sem "montá-lo" primeiro?
Observe que isso acontece automaticamente em muitos sistemas operacionais (até mesmo no Linux em algumas distribuições e interfaces gráficas), mas isso não significa que outros sistemas operacionais não estejam "montando" as unidades.
Responder3
Eu chamaria isso de razões históricas. Não que as outras respostas estejam erradas, mas há um pouco mais nesta história.
Compare o Windows: O Windows começou como um sistema operacional de computador único e usuário único. Esse único computador provavelmente tinha uma unidade de disquete e um 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 ser extravagante: basta montar tudo (todos os dois dispositivos) automaticamente todas as vezes, não há (não havia) muitas coisas que pudessem dar errado.
Em contraste, o Unix foi criado para rodar em redes de servidores com múltiplos usuários desde o início.
Uma das decisões de design do Unix foi que o sistema de arquivos deveria aparecer como uma entidade única e uniforme para os usuários finais, não importando em quantos computadores os discos físicos estivessem espalhados, não importando que tipo de disco e em qual das dezenas de computadores. o usuário o acessaria. O caminho lógico para os arquivos do usuário permaneceria o mesmo, mesmo que a localização física desses arquivos tivesse mudado durante a noite, por exemplo, devido à manutenção do servidor.
Eles estavam abstraindo o sistema de arquivos lógico, os caminhos para os arquivos, dos dispositivos físicos que armazenavam esses arquivos. Digamos que o servidor A normalmente esteja hospedando/home, mas o servidor A precisa de manutenção: basta desmontar o servidor A e montar o servidor de backup B em/home, e ninguém além dos administradores notaria.
(Ao contrário da convenção do Windows de dar nomes diferentes a diferentes dispositivos físicos - C:, D:, etc. - que vai contra a transparência que o Unix buscava.)
Nesse tipo de cenário, você não pode simplesmente montar tudo à vista, querendo ou não,
Em uma rede grande, discos e computadores individuais ficam constantemente fora de serviço. Administradoresprecisara capacidade de dizer o que está montado, onde e quando, por exemplo, fazer um desligamento controlado de um computador enquanto outro computador assume de forma transparente a hospedagem dos mesmos arquivos.
É por isso que, de uma perspectiva histórica: o Windows e o Unix vieram de origens diferentes. Você poderia chamar isso de diferença cultural, se quiser:
- O Unix nasceu em um ambiente onde 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 onde não havia administrador e apenas dois dispositivos de armazenamento, e o usuário provavelmente saberia se seu arquivo estava no disquete ou no disco rígido.
- (O Linux nasceu como um sistema operacional para um único computador, é claro, mas também foi explicitamente projetado desde o início para imitar o Unix o mais próximo possível de um computador doméstico.)
Mais recentemente, os sistemas operacionais têm se aproximado uns dos outros:
- O Linux adicionou mais recursos de computador único e usuário único (como montagem automática); já que se tornou frequentemente usado em configurações de um único computador.
- O Windows adicionou mais segurança, rede, suporte para vários usuários, etc.; à medida que as redes se tornaram mais onipresentes e a Microsoft começou a criar um sistema operacional para servidores também.
Mas ainda é fácil dizer que os dois são resultado de tradições diferentes.
Responder4
O título da pergunta pergunta:Por que precisamos montar no Linux?
Uma maneira de interpretar esta questão: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, você pode fazer com que isso seja feito automaticamente, e as distribuições Linux já fazem isso para a maioria dos dispositivos, assim como o Windows e o Mac fazem.
Então provavelmente não foi isso que você quis perguntar.
Uma segunda interpretação:Por que nósàs vezesprecisa emitir mountcomandos explícitos para disponibilizar sistemas de arquivos no Linux? Por que não fazer o sistema operacionalsemprefazer isso por nós e ocultar do usuário?
Esta é a pergunta que estou lendo no texto da pergunta, quando você pergunta:
Por que não pular totalmente a montagem e fazer o seguinte
ls /dev/cdrom
e tem o conteúdo do CD-ROM listado?
Presumivelmente, você quer dizer: por que não 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 questão parece ser: por que ter um arquivo de dispositivo em primeiro lugar?
Gostaria de acrescentar uma resposta às já dadas.
Por que os usuários conseguem ver os arquivos do dispositivo?
Sempre que você usa um CD-ROM ou qualquer outro dispositivo que armazene arquivos, é usado um software que interpreta tudo o que está no seu CD-ROM como uma árvore de diretórios de arquivos. Ele é invocado sempre que você usa lsqualquer outro tipo de comando ou aplicativo que acesse os arquivos do seu CD-ROM. Esse software é o driver do sistema de arquivos para o sistema de arquivos específico usado para gravar os arquivos em seu CD-ROM. Sempre que você lista, lê ou grava arquivos em um sistema de arquivos, é função desse software garantir que as operações correspondentes de leitura e gravação de baixo nível sejam executadas no dispositivo em questão. Sempre que você cria mountum sistema de arquivos, informa ao sistema qual driver de sistema de arquivos usar para o dispositivo. Quer você faça isso explicitamente com um mountcomando ou deixe que o sistema operacional seja feito automaticamente, isso 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: isso é feito lendo e gravando no arquivo do dispositivo. Por que? A resposta, como você já afirmou: o Unix foi projetado dessa forma. No Unix, os arquivos de dispositivos são a abstração comum de baixo nível 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 de sistema de arquivos) não precisa saber tanto sobre o funcionamento interno de dispositivos individuais. Os drivers de dispositivo de baixo nível e os drivers do sistema de arquivos podem ser escritos separadamente, por pessoas diferentes, desde que concordem com uma forma comum de interface entre si, e é para isso que servem os arquivos de 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. Ele foi projetado para permitir que seus usuários escrevessem drivers de dispositivos e drivers de sistema de arquivos. Na verdade, é assim que eles são escritos.
O mesmo se aplica ao Linux: você pode escrever seu próprio driver de sistema de arquivos (ou driver de dispositivo), instalá-lo e usá-lo. Isso 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 alguma nova peça de hardware chega ao mercado, ou quando uma maneira nova e mais inteligente de implementar um sistema de arquivos é projetada , alguém pode escrever o código para suportá-lo, fazê-lo funcionar e contribuir para o Linux.
Os arquivos do dispositivo tornam isso mais fácil.