☰

Como o Linux armazena a pasta de mapeamento -> file_name -> inode?

tag-icon • tag-icon filesystems inode
Como o Linux armazena a pasta de mapeamento -> file_name -> inode?

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

Diretórios Unix são listas de estruturas de associação, cada uma contendo um nome de arquivo e um número de inode.

Então, eu esperava descobrir que cada diretório conteria os nomes dos arquivos contidos nele, com cada arquivo mapeado para um inode. Mas quando faço isso vim directory_nameno Ubuntu, 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 próximo a cada nome de arquivo. Por que não é esse o caso?

Responder1

Essa citação é sobre como (logicamente – as estruturas reais são muitas vezes muito diferentes hoje em dia) os sistemas de arquivos Unix funcionam. E você pode ver os números dos inodes com, por exemplo, o -isinalizador 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 hardlink), 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 e tamanho fazem parte do inode, não do diretório. Fácil de ver pelo que acontece depois 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

ambos be calterados, porque compartilham o mesmo inode.

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

Então, basicamente, vim direstá apenas mostrando uma lista de diretórios - mais ou menos como lsfaz. Isso é feito através de um módulo vim chamado Netrw, como diz acima (tente :help netrwno vim). Na verdade, você não pode editar as estruturas de dados subjacentes do sistema de arquivos.

Responder2

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. Os aplicativos podem designar arquivos por nome e enumerar a lista de arquivos em um diretório, e cada arquivo possui um designador exclusivo chamado “inode”.

A forma 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 inode, e há uma tabela separada que mapeia números de inode para dados de inode. (Os dados do inode contêm metadados do arquivo, como permissões e carimbos de data e hora, a localização do conteúdo do arquivo, etc.) O mapeamento pode ser uma lista, uma tabela 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. Os diretórios agem como arquivos comuns no que diz respeito à entrada do diretório e aos metadados, mas não no que diz respeito ao conteúdo. Os aplicativos leem arquivos comuns com chamadas de sistema como open, read, write, close; para diretórios existem outras chamadas de sistema: opendir, readdir, closedire a modificação de um diretório é feita criando, movendo e excluindo arquivos. Um aplicativo como catusa open, read, closepara ler o conteúdo de um arquivo; um aplicativo como lsusa opendir, readdir, closedirpara ler o conteúdo de um diretório. O Vim normalmente funciona como catler o conteúdo de um arquivo, mas se você pedir para ele abrir um diretório, ele funciona lse imprime os dados de uma forma bem formatada.

Se você quiser ver a aparência de um diretório, você pode usar uma ferramenta como debugfsext2/ext3/ext4. Certifique-se de não modificar nada! Uma ferramenta como essa debugfsignora 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 a gravação por meio 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 do diretório em /meio a vários outros caracteres, alguns não imprimíveis. Para entender isso, você precisa conhecer os detalhes do formato do sistema de arquivos.

Responder3

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

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

informação relacionada