Arquivar arquivos de montagem versus montar diretórios [duplicados]

Question

Eu estava lendo problema com a compreensão do conceito de montagem e nos deparamos com essa explicação:

By using mount -t iso9660 /dev/cdrom /media/cdrom, you tell the system: "take this very long string of bytes that you have in /dev/cdrom, interpret it as a directory tree in the iso9660 format, and allow me to access it under the location /media/cdrom"

e outras respostas ao longo desta linha. Isso faz sentido e, a partir dessa lógica, entendi que montar essencialmente casais um sistema de arquivos para um dispositivo que interpreta o conteúdo do dispositivo de forma que o kernel possa encaixá-lo na hierarquia existente do sistema de arquivos.

Se este é realmente o caso, por que é necessário montar um laço?

Como mount -o loop é tecnicamente idêntico à operação que mount pretende: ler um arquivo e interpretar seu conteúdo no contexto de um sistema de arquivos, por que não podemos generalizar a operação de montagem sem criar um dispositivo especial?

Editar : Eu entendo que um dispositivo de loop fornece uma API de dispositivo de bloco a um arquivo. Minha pergunta é, no entanto, mais geral. Como a leitura de um arquivo regular ( iso ou formatos de imagem de disco semelhantes) difere da leitura de um arquivo especial, se eles contêm os mesmos dados?

Meu modelo mental de como mount funciona é este: dado um conjunto arbitrário de bytes expostos por um arquivo /dev/device que são consequentemente interpretados por um driver do sistema de arquivos ( ext4 , por exemplo), o comando mount associa-o à hierarquia raiz para que pareça transparente para o usuário final.

No entanto, esse conjunto arbitrário de bytes pode ocorrer em qualquer lugar. Se interpretados por um driver do sistema de arquivos, eles devem ser reconhecidos como um sistema de arquivos válido. O que restringe um driver do sistema de arquivos para ler somente de um arquivo especial e não de um arquivo normal?

    

Answer 1

Dispositivos de bloco não são arquivos normais, eles permitem que programas como o mount executem funções especiais que são necessárias para que ele funcione corretamente.

Um dispositivo de loop é um dispositivo de conversão, traduz chamadas de arquivo de bloco em chamadas normais do sistema de arquivos para um arquivo específico. Você pode usar losetup para criar dispositivos de loopback de pleno direito apoiados por um arquivo (aparecerá como /dev/loopX e, em seguida, tratá-los como dispositivos de bloco normais ou passar -o loop para montar, para criar o dispositivo de bloco de forma transparente. use também losetup para inspecionar os dispositivos de loopback e o que eles suportam.

Note que com a montagem moderna, ele tentará detectar um arquivo normal e criará automaticamente o dispositivo de loopback para você. Então você não precisa passar a opção loop .

Além disso, tecnicamente um bind mount é onde você remonta um diretório para um novo local (por isso, ele é montado duas vezes). Isso pode ser feito com o sinalizador --bind para montar. Eu entendo o seu significado, mas pode ficar confuso, pois o termo bind tem um significado específico em termos de montagem.

Editar: O modelo mental está efetivamente correto, mas você pode pensar em dispositivos de loop como uma camada de abstração, ele permite que o mount converse com qualquer arquivo como se fosse um dispositivo de bloco, sem precisar Entender as diferenças entre leitura / gravação para um sistema de arquivos ou para um dispositivo de bloco raw - o kernel lida com tudo isso. Tudo o que o mount precisa saber é como pedir ao kernel para configurar o dispositivo de loop, então trata-se de um dispositivo de bloco; isso mantém o código de baixo nível mais simples e permite que qualquer coisa que possa falar com um dispositivo de bloco converse com um arquivo sem ser modificada.

    

Answer 2

Descrito vagamente, uma montagem de loop redireciona a montagem como um "dispositivo de loop".

Um "dispositivo de loop" é efetivamente representativo de uma partição física (que normalmente representa blocos de dispositivos sequenciais), mas deve ser interpretado através do sistema de arquivos no qual a imagem reside em um estado potencialmente fragmentado.

Ao contrário de uma partição física, o sistema de arquivos subjacente deve ser consultado para cada bloco lido. É menos eficiente, embora mais conveniente, e permite sistemas de arquivos aninhados de diferentes tipos de sistemas de arquivos.

Um mount -o loop é não tecnicamente idêntico a uma operação mount mais do que usar swapon para um arquivo de permuta é idêntico ao uso de swapon para uma partição swap.

Em uma partição real, as leituras e gravações são restritas aos limites físicos da partição / cilindro. A fragmentação é ofuscada pelo sistema de arquivos da partição.

Em uma imagem em loop, a fragmentação fica oculta atrás de uma montagem sequencial aparentemente . O sistema de arquivos subjacente manipula a fragmentação de arquivos e apresenta uma "partição" sequencial.

Isso se torna mais aparente no caso de imagens de disco criptografadas ou compactadas, como squashfs . Nesses casos, os referidos blocos de imagem são acessados através do sistema de arquivos subjacente e, em seguida, processados através da API de compactação (ou criptografia) aplicável para apresentar um conjunto aparentemente seqüencial de blocos de dispositivos.

Em suma, espera-se que um "dispositivo de bloco" seja uma lista sequencial de "blocos de dispositivos". O dispositivo especial criado por um loop mount finge que blocos de dispositivos potencialmente não sequenciais de tamanhos variados são blocos de dispositivos sequenciais de um tamanho predeterminado.