Por que precisamos montar no Linux?

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.