Como uma entrada de diretório de ponto de montagem é diferente de uma entrada de diretório comum em um sistema de arquivos

Question

Eu sei que um diretório é um arquivo contendo linhas tipo "name = inode number".

Quando eu solicito um caminho como /home/my_file.txt, as próximas etapas ocorrem:

1. Ir para o inode número 2 (inode padrão do diretório raiz)
2. Obter o arquivo para o qual o inode # 2 está apontando.
3. Pesquise por esse arquivo e encontre a entrada "inicial". Obtenha seu número de inode, por exemplo, 135.
4. Obter o arquivo para o qual o inode # 135 está apontando.
5. Pesquise por este arquivo e encontre a entrada "my_file.txt". Obtenha seu número de inode, por exemplo, 245.
6. Obter o arquivo para o qual o inode # 245 está apontando.

A questão: como este processo é diferente no caso de o diretório home ser o ponto de montagem de outro sistema de arquivos, residindo em outro dispositivo de bloco? Quando o sistema entende, esse diretório é o ponto de montagem e como ele faz isso? Onde esta informação é armazenada - no inode, no arquivo de diretório ou em outro lugar?

Por exemplo, parte da listagem do meu diretório raiz com números de inodes exibidos:

ls -d1i /*/

inode # name
656641  /bin/
2       /boot/
530217  /cdrom/
2       /dev/
525313  /etc/
2       /home/
393985  /lib/

Aqui, os diretórios home e boot são pontos de montagem e residem em sistemas de arquivos próprios. Execute meu algoritmo de pseudocódigo (escrito acima) e cole na etapa número 3 - nesse caso, o número de inode inicial é 2 e está localizado em outro sistema de arquivos e em outro dispositivo de bloco.

    

Answer 1

Sua descrição do processo não está correta.

O kernel controla quais caminhos são pontos de montagem. Exatamente como isso varia entre o kernel, mas normalmente as informações são armazenadas em termos de caminhos. Por exemplo, o kernel lembra “ / é este sistema de arquivos, /media/cdrom é este sistema de arquivos, /proc é este sistema de arquivos”, etc. Normalmente, em vez de uma cadeia de mapeamento de tabelas para estruturas de dados representando sistemas de arquivos montados, o kernel armazena tabelas por diretório. Os dados associados a uma entrada de diretório são classicamente chamados de dentry . Há um dentry para a raiz, e em cada diretório há um dentry para cada arquivo naquele diretório que o kernel lembra. O dentry contém um ponteiro para uma estrutura de inode, e o inode contém um ponteiro para a estrutura de dados do sistema de arquivos para o sistema de arquivos no qual o arquivo está. Em um ponto de montagem, o sistema de arquivos associado é diferente do sistema de arquivos associado do dentry pai, e há metadados adicionais para acompanhar o ponto de montagem. Portanto, em uma arquitetura de kernel unix típica, o dentry para / contém um ponteiro para informações sobre o sistema de arquivos raiz, além de um ponteiro para o inode que contém o diretório raiz; o dentry para /proc (assumindo que é um ponto de montagem) contém um ponteiro para informações sobre o sistema de arquivos proc, etc. Se /media/cdrom é um ponto de montagem mas não /media , o kernel se lembra do /media que não é permitido esquecê-lo: lembrar sobre /media não é apenas uma questão de cache para desempenho, é necessário lembrar a existência do ponto de montagem /media/cdrom .

Para Linux, você pode encontrar documentação na documentação do kernel , no site e em outros lugares da web. Bruce Fields tem uma boa apresentação do tópico.

Quando o kernel é instruído a acessar um arquivo, ele processa o nome do arquivo um componente separado por barra de cada vez e procura o componente a cada vez. Se encontrar um link simbólico, segue-o. Se encontrar um ponto de montagem, nenhum processamento especial é realmente necessário: é apenas que os inodes estejam anexados a um diretório diferente.

O processo não usa números de inodes, segue ponteiros . Os números de inodes são uma maneira de fornecer uma identidade única para cada arquivo em um determinado sistema de arquivos fora do kernel: no disco e para aplicativos. Existem sistemas de arquivos que não possuem números de inodes exclusivos; Normalmente, os drivers do sistema de arquivos tentam criar um, mas isso nem sempre funciona, especialmente com sistemas de arquivos de rede (por exemplo, se o servidor exportar uma árvore de diretórios que contenha um ponto de montagem, pode haver sobreposição entre o conjunto de inodes acima e abaixo da montagem) ponto). Linhas que mapeiam o nome para o número de inode são o modo como um sistema de arquivos típico em disco funciona se ele suportar links físicos; sistemas de arquivos que não suportam hard links realmente não precisam do conceito de inode number.

Observe que as informações sobre pontos de montagem são armazenadas somente na memória. Quando você monta um sistema de arquivos, isso não modifica o diretório em cima do qual o sistema de arquivos é montado. Esse diretório é simplesmente oculto pela raiz do sistema de arquivos montado.

    

Answer 2

Não sei se isso pode ser respondido em geral, pois é um problema de implementação. Claro, o sistema operacional tem que saber de alguma forma que um determinado diretório é um ponto de montagem, mas cabe aos escritores do SO considerar como isso é feito. Eu não tenho idéia dos componentes internos do Linux, BSD, Solaris ou qualquer outra coisa e não ouso assumir nenhuma semelhança ou diferença entre eles.

Como suposição, acho que podemos identificar um inode de forma exclusiva pelo par {device, inode} ( st_dev e st_ino em struct stat ). Supondo que links rígidos para diretórios são proibidos, um diretório inode também teria um nome exclusivo.

Assim, uma maneira seria ter uma tabela de todos os pontos de montagem no sistema, que o sistema operacional veria em cada diretório ao percorrer um caminho.

Se o sistema tiver algum tipo de cache para inodes (uma otimização útil), poderíamos ignorar a pesquisa completa da tabela adicionando um sinalizador ou ponteiro na estrutura inode in-memory para informar se esse inode é um ponto de montagem ou não.

    

Answer 3

Quando um sistema de arquivos é montado em um determinado ponto de montagem, o SO lê o Super-bloco do sistema de arquivos montado e o carrega na memória. Um Super-bloco, juntamente com muitas outras coisas, contém informações sobre o inode da raiz desse sistema de arquivos.

Os pontos acima estão corretos de que existem estruturas de dados do SO que mantêm registros de todos os sistemas de arquivos montados, se outro sistema de arquivos tiver sido montado em / home /, o Super-bloco do sistema de arquivos será consultado para obter o número de inode do diretório raiz.