Como o linux armazena a pasta de mapeamento - file_name - inode?

Question

Comecei a ler um pouco sobre o sistema de arquivos linux. Em vários lugares encontrei citações como esta:

Unix directories are lists of association structures, each of which contains one filename and one inode number.

Então eu esperava descobrir que cada diretório conteria os nomes dos arquivos sob ele, com cada arquivo mapeado para um inode. Mas quando eu faço vim directory_name no Ubuntu, eu recebo algo assim:

" ============================================================================
" Netrw Directory Listing                                        (netrw v156)
"   /Users/user/workspace/folder
"   Sorted by      name
"   Sort sequence: [\/]$,\<core\%(\.\d\+\)\=\>,\.h$,\.c$,\.cpp$,\~\=\*$,*,\.o$,\.obj$,\.info$,\.swp$,\.bak$,\~$
"   Quick Help: <F1>:help  -:go up dir  D:delete  R:rename  s:sort-by  x:special
" ==============================================================================
../
./
folder1/
folder2/
file1
file2

Eu esperava ver um número de inode ao lado de cada nome de arquivo, por que não é esse o caso?

    

Answer 1

Um diretório é, semanticamente falando, um mapeamento do nome do arquivo para o inode. É assim que a abstração da árvore de diretórios é projetada, correspondendo à interface entre aplicativos e sistemas de arquivos. Aplicativos podem designar arquivos pelo nome e enumerar a lista de arquivos em um diretório, e cada arquivo tem um designador exclusivo que é chamado de “inode”.

Como essa semântica é implementada depende do tipo de sistema de arquivos. Cabe a cada sistema de arquivos como o diretório é codificado. Na maioria dos sistemas de arquivos Unix, um diretório é um mapeamento de nomes de arquivos para números de inodes, e há uma tabela separada que mapeia números de inode para dados de inode. (Os dados do inode contêm metadados de arquivos, como permissões e registros de data e hora, a localização do conteúdo do arquivo etc.). O mapeamento pode ser uma lista, uma tabela de hash, uma árvore ...

Você não pode ver esse mapeamento com o Vim. O Vim não mostra a área de armazenamento que representa o diretório. O Linux, como muitos outros sistemas Unix modernos, não permite que os aplicativos vejam a representação do diretório diretamente. Diretórios agem como arquivos comuns quando se trata de sua entrada de diretório e seus metadados, mas não quando se trata de seu conteúdo. Aplicativos lidos do arquivo comum com chamadas do sistema, como open , read , write , close ; para diretórios, há outras chamadas do sistema: opendir , readdir , closedir e a modificação de um diretório é feita criando, movendo e excluindo arquivos. Um aplicativo como cat usa open , read , close para ler o conteúdo de um arquivo; um aplicativo como ls usa opendir , readdir , closedir para ler o conteúdo de um diretório. O Vim normalmente funciona como cat para ler o conteúdo de um arquivo, mas se você pedir para ele abrir um diretório, ele funciona como ls e imprime os dados de uma maneira bem formatada.

Se você quiser ver como é um diretório sob o capô, você pode usar uma ferramenta como debugfs para ext2 / ext3 / ext4. Certifique-se de não modificar nada! Uma ferramenta como debugfs ignora o sistema de arquivos e pode destruí-lo completamente. O ext2 / ext3 / ext4 debugfs é seguro porque está no modo somente leitura, a menos que você permita explicitamente escrever através de uma opção de linha de comando.

# debugfs /dev/root
debugfs 1.42.12 (29-Aug-2014)
debugfs: dump / /tmp/root.bin
debugfs: quit
# od -t x1 /tmp/root.bin

Você verá os nomes das entradas de diretório em / em meio a um monte de outros caracteres, alguns não imprimíveis. Para entender, você precisa conhecer os detalhes do formato do sistema de arquivos.

    

Answer 2

Essa citação é sobre como (logicamente - as estruturas atuais são frequentemente muito diferentes hoje em dia). Sistemas de arquivos Unix funcionam. E você pode ver os números de inode com, por exemplo, o -i flag para ls :

$ ls -li
total 8
532028 -rw-r--r-- 1 anthony anthony 115 Apr 25 12:07 a
532540 -rw-r--r-- 1 anthony anthony  70 Apr 25 12:07 b

Esse número à esquerda é o inode. E se eu executar ln b c (criando um link físico), então:

$ ls -li
total 12
532028 -rw-r--r-- 1 anthony anthony 115 Apr 25 12:07 a
532540 -rw-r--r-- 2 anthony anthony  70 Apr 25 12:07 b
532540 -rw-r--r-- 2 anthony anthony  70 Apr 25 12:07 c

As permissões & tamanho faz parte do inode, não do diretório. Fácil o suficiente para ver o que acontece depois de chmod 0600 c :

$ ls -li
total 12
532028 -rw-r--r-- 1 anthony anthony 115 Apr 25 12:07 a
532540 -rw------- 2 anthony anthony  70 Apr 25 12:07 b
532540 -rw------- 2 anthony anthony  70 Apr 25 12:07 c

b e c foram alterados porque compartilham o mesmo inode.

No entanto, o kernel só expõe o sistema de arquivos ao userspace através de uma API bem definida (exceto para os dispositivos brutos como /dev/sda1 ). Ele dá acesso ao espaço do usuário para um monte de syscalls para fazer coisas como criar e remover links, alterar permissões, ler e gravar em arquivos, renomear, etc. Ele não expõe as estruturas de dados cruas do sistema de arquivos ao userspace. Por vários bons motivos: permite sistemas de arquivos de rede, significa que o kernel pode impor permissões e manter as estruturas de dados do sistema de arquivos corretas, isso significa que você pode usar diferentes sistemas de arquivos (com estruturas de dados diferentes) sem precisar alterar o espaço do usuário. / p>

Então, basicamente, vim dir está mostrando apenas uma listagem de diretórios - mais ou menos como ls . É feito através de um módulo vim chamado Netrw, como diz acima (tente :help netrw no vim). Você não pode realmente editar as estruturas de dados subjacentes do sistema de arquivos.

    

Answer 3

Eu suspeito que você esteja lendo uma exposição muito antiga sobre como o sistema de arquivos Unix funciona. O que você descreve teria sido verdade no final dos anos 1970, mas não é mais verdadeiro em nenhum sistema de arquivos moderno.

Em muitas plataformas modernas, há vários sistemas de arquivos em uso comum, e cada um deles oculta seus componentes internos do espaço do usuário. Você pode descobrir como eles são e brincar com eles, mas a menos que você queira se especializar em projetar sistemas de arquivos, talvez seja melhor confiar apenas no autor do livro para ter o suficiente para ter um entendimento básico do design, sem entrar em muitos detalhes (alguns dos quais serão obsoletos quando você precisar novamente)