Por que precisamos montar no Linux?

Question

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

Por exemplo, conforme explicado na resposta aceita desta questão , usando este comando:

mount /dev/cdrom /media/cdrom

estamos montando o dispositivo de CDROM em /media/cdrom e, eventualmente, podemos 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 fazer o seguinte?

ls /dev/cdrom

E tenha o conteúdo do CD-ROM listado. Espero que uma das respostas seja: " É assim que o Linux é projetado ". Mas se assim for, então por que foi projetado dessa maneira? Por que não acessar o diretório /dev/cdrom diretamente? Qual é o propósito real da montagem?

    

Answer 1

Uma razão é que o acesso em nível de bloco é um nível um pouco mais baixo do que o ls poderia trabalhar. /dev/cdrom , ou dev/sda1 pode ser sua unidade de CD-ROM e partição 1 do seu disco rígido, respectivamente, mas eles não estão implementando ISO 9660 / ext4 - eles são apenas ponteiros RAW para os dispositivos conhecidos como Device Files .

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

Outras vezes, esse acesso de baixo nível pode ser bom o 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, localizar o arquivo blocos de armazenamento, leia o bloco completo, faça minhas alterações, escreva os blocos completos, então atualize o inode (talvez), ou escreva tudo isso para o periódico - 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 cd e ls tudo que você gosta. /dev/sda1 não é um diretório; é um tipo especial de arquivo que é o que o kernel oferece como 'manipulador' para aquele dispositivo.

Veja a entrada da wikipedia em arquivos de dispositivos para um tratamento mais aprofundado.

    

Answer 2

Basicamente, e para colocá-lo facilmente, o sistema operacional precisa saber como acessar os arquivos nesse dispositivo.

mount não é apenas "dando acesso aos arquivos", está dizendo ao SO 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ê tenha colocado um cdrom estranhamente formatado nele (mesmo um CD de áudio), como ls tell quais arquivos (se houver) existem no cd-rom sem "montar" primeiro?

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

    

Answer 3

Para consistência

Imagine que você tenha algumas partições no primeiro disco rígido do seu sistema. Por exemplo, /dev/sda2 . Posteriormente, 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/sda e sua unidade atual se torna /dev/sdb . Sua partição agora é /dev/sdb2 .

Usando seu sistema proposto, você teria que alterar todos os scripts, aplicativos, configurações etc. que acessam os dados da 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 essa unidade renomeada. Você teria que editar /etc/fstab para informar ao seu sistema que (por exemplo) /media/backup agora é /dev/sdb2 , mas isso é apenas uma edição.

Observe que os sistemas modernos são ainda mais fáceis. Em vez de fazer referência ao dispositivo como /dev/sda2 ou /dev/sdb2 , eles têm UUIDS , que são semelhantes a c5845b43-fe98-499a-bf31-4eccae14261b ou podem receber rótulos mais amigáveis, como backup , que podem ser usados para fazer referência ao 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

Para 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 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 diz que é seguro remover um pendrive USB? Isso é o Windows montar e desmontar o pau para você. Então o princípio não é apenas Unix / Linux.

    

Answer 4

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 começou como um sistema operacional de usuário único de computador ú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 tinha .)

O tipo de cenário 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) muitas coisas que poderiam dar errado .

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

Uma das decisões de design do Unix era 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, não importando o tipo de disco, dezenas de computadores que o usuário iria acessá-lo. O caminho lógico para os arquivos do usuário permaneceria o mesmo, mesmo que a localização física desses arquivos tivesse sido alterada 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 hospeda / 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 funciona contra a transparência pela qual o Unix estava se esforçando).

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 estão constantemente fora de operação. Os administradores precisam da capacidade de dizer o que é montado onde e quando, por ex. para fazer um desligamento controlado de um computador, enquanto outro computador passa a hospedar os mesmos arquivos de forma transparente.

Então é por isso que, do ponto de vista histórico: o Windows e o Unix vieram de origens diferentes. Você poderia chamar isso de uma diferença cultural, se você 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 é montado onde e quando.
• O Windows nasceu em uma configuração 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 SO de computador único, é claro, mas também foi explicitamente projetado desde o início para imitar o Unix da melhor forma possível em um computador doméstico.)

Mais recentemente, os sistemas operacionais estão se aproximando:

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

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

    

Answer 5

Existem várias vantagens para o 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 que o unix foi construído é tudo é um arquivo. Isso simplifica muitas coisas, por exemplo, a interação do usuário é apenas leituras e gravações de arquivos em um dispositivo tty, que é um arquivo especial de caractere. Da mesma forma, a verificação de blocos defeituosos, o particionamento ou a formatação de um disco é apenas uma operação de arquivo. Não importa se o disco é mfm, ide, scsi, fiberchanel ou 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 os que cabem em um disco. Então nós temos pontos de montagem. Um ponto de montagem permite que você coloque 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ê poderia colocar / em uma unidade e / home em outra.

Agora notei que você mencionou a montagem do 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ê poderia certamente usar / media / cdrom2, etc. Ou você poderia montá-lo em / src / samba / resources / windows-install, ou / var / www, ou onde quer que seja sensato fazer isso.

    

Answer 6

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

link

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

    

Answer 7

Porque /dev/cdrom é um dispositivo, enquanto /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 do seu dispositivo de disco rígido físico, quando você inicializa o computador. Isso é apenas adicionar mais sistemas de arquivos para usar.

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

    

Answer 8

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

Uma forma de interpretar esta questão: Por que precisamos emitir comandos mount 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 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 Macs fazem.

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

Uma segunda interpretação: Por que às vezes precisamos emitir comandos mount explícitos para disponibilizar sistemas de arquivos no Linux? Por que não fazer o sistema operacional sempre faz isso por nós, e esconde isso 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 fazer o seguinte

ls /dev/cdrom

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

Presumivelmente, você quer dizer: por que não apenas ter esse comando fazer o que

ls /media/cdrom

faz agora?

Bem, nesse caso, /dev/cdrom seria uma árvore de diretórios, não um arquivo de dispositivo. Então, sua verdadeira questão parece ser: por que um arquivo de dispositivo em primeiro lugar?

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

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

Sempre que você usar um CD-ROM ou qualquer outro dispositivo que armazene arquivos, um software é usado para interpretar o que estiver em seu CD-ROM como uma árvore de diretórios de arquivos. Ele é invocado sempre que você usa ls ou qualquer outro tipo de comando ou aplicativo que acessa os arquivos em seu CD-ROM. Esse software é o driver do sistema de arquivos para o sistema de arquivos específico 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 correspondentes de leitura e gravação de baixo nível sejam executadas no dispositivo em questão. Sempre que você mount um sistema de arquivos, você está dizendo ao sistema qual driver do sistema de arquivos deve ser usado para o dispositivo. Se você fizer isso explicitamente com um comando mount , ou deixá-lo para o sistema operacional ser 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: é ler e gravar 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 comum de baixo nível para dispositivos. O software realmente específico do dispositivo (o driver de dispositivo) para um dispositivo específico deve implementar a abertura, fechamento, leitura e gravação no dispositivo como operações no arquivo do dispositivo. Dessa forma, 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 gravados separadamente, por pessoas diferentes, desde que eles concordem com uma maneira comum de interface 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, vemos 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 gravem drivers de dispositivo e drivers de sistema de arquivos. Isso é, de fato, como eles são escritos.

O mesmo vale para o Linux: você pode escrever seu próprio driver de sistema de arquivos (ou driver de dispositivo), instalá-lo e depois usá-lo. Isso torna o Linux (ou qualquer outra variante do Unix) facilmente extensível (e é de fato o motivo pelo qual o Linux foi iniciado): quando uma nova peça de hardware é lançada no mercado ou uma maneira nova e mais inteligente de implementar um sistema de arquivos , alguém pode escrever o código para apoiá-lo, fazê-lo funcionar e contribuir para o Linux.

Arquivos de dispositivos facilitam isso.

    

Answer 9

Isso acontece porque existe, com muitas mídias para interfaces de usuário 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 para, digamos, inseri-lo 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 de maneira semelhante, e não há maneira de os computadores manipularem montagens de rede da maneira mais intuitiva possível para montagens de rede com outras interfaces de usuário. a computadores, como smartphones, tablets e computadores vestíveis, que não têm a possibilidade de inserir mídia física nos dispositivos. (Observe como a interface do iPhone é horrível para trocar cartões SIM, o tipo de dispositivo iOS de mídia física foi inserido neles.

Observe também que outras abordagens populares de 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)) os mesmos problemas e usar caixas de diálogo GUI adicionais para resolver a confusão potencial (por exemplo, o Windows 8 é normalmente configurado para solicitar cada novo CD inserido, seja ele montado como um sistema de arquivos, uma mídia musical ou, se apropriado, uma coleção de vídeos MP4). Não há razão para que qualquer um desses diálogos de usuários não possa ser usado com o Linux ou outros UNIXes.