Atualmente estou lendo o livro Advance UNIX Programming de W. Richard Stevens e li lá que todos os arquivos no UNIX têm um número e que os nomes dos arquivos são criados apenas para conveniência do usuário. Quando um diretório é inserido, o sistema procura o número do nome inserido.
Pensei comigo mesmo: como eles procuram o número? Os arquivos são armazenados classificados por nome para que possam ser encontrados por pesquisa binária? Ou eles apenas acrescentam novos arquivos ao final da lista?
Responder1
Existem muitos formatos de sistemas de arquivos diferentes e eles fazem compromissos diferentes entre desempenho em diferentes cenários (diretórios grandes versus diretórios pequenos, leitura versus gravação, acesso simultâneo,…), simplicidade de design (probabilidade de bugs, esforço de desenvolvimento,…), sobrecarga de disco (espaço usado para outras coisas além do conteúdo do arquivo), etc.
Sistemas de arquivos mais antigos (por exemploUFS, FFS,ext2, originalext3, …) tendem a armazenar diretórios como uma matriz de entradas (cada entrada contém um nome de arquivo, um número de inode e possivelmente alguns metadados adicionais) e a fazer uma pesquisa linear. Novos arquivos são adicionados na primeira entrada livre no array; se não houver entrada livre, a matriz é primeiro ampliada. Isso resulta em desempenho ruim com diretórios grandes.
Sistemas de arquivos mais recentes (por exemploext3com a dir_indexopção,ext4,zfs,btrfs,reiserfs,HFS,HFS+,…) tendem a armazenar diretórios como uma estrutura de dados com pesquisa em tempo logarítmico, algum tipo de árvore de pesquisa balanceada, tabela hash ou uma combinação dos dois (árvore de pesquisa balanceada de hashes) - normalmente alguma variante de umÁrvore B. Isso torna o código do sistema de arquivos mais complexo, mas mantém um bom desempenho com diretórios grandes.
Responder2
O número é chamado deinode. Ext4, um dos tipos de sistema de arquivos Linux mais populares, faz uso de uma árvore hash, vejakernel.org - Layout de disco Ext4.
Mais detalhes sobre árvores hash emWikipédia.
Responder3
Isso depende do sistema de arquivos. Há muito tempo, o diretório Unix era essencialmente um arquivo que consistia em registros de 16 bytes, dois bytes para o número interno e 14 bytes para o nome do arquivo. Esta é a razão para o antigo limite de 14 caracteres nos nomes de arquivos. Os registros não foram ordenados, portanto foi necessária uma busca linear no arquivo.
Sistemas de arquivos mais modernos, como o Ext4 do Linux, possuem uma tabela hash para acelerar a pesquisa.
Responder4
Alerta pedante: a descrição não está completa. Os nomes dos arquivos não podem ser descritos apenas como uma conveniência para os usuários. Os nomes dos arquivos acabaram sendoextremamenteimportante em sistemas baseados em Unix.
Os números dos inodes não podem ter significado porque são escolhidos pelo módulo do sistema de arquivos. Originalmente, eles identificaram um slot na tabela de inodes armazenada no disco. As outras partes do sistema precisam acessar arquivos que tenham um significado específico, por exemplo, /dev/tty1ou /etc/passwd.
Sem limitar você a uma palavra específica, "conveniência" é muito trivial para descrever o mecanismo, que é usado para fornecer a interface do usuário para selecionar comandos como catou edpor nome.
Se não existissem diretórios de nomes de arquivos, muito em breve você teria que inventar alguns registros de nomes muito semelhantes para os números de inode para suportar esses usos.
As entradas do diretório .também ..têm um significado especial. Sistemas de arquivos virtuais como procfornecem seu próprio significado usando nomes de arquivos, por exemplo, disponibilizando /proc/1/commpara fornecer informações sobre o processo 1. O VFS também permite o uso de diferentes sistemas de arquivos, que não precisam ser baseados em unix e podem não funcionar exatamente com o mesmo conceito de números de inodes.
O ZFS parece pensar que os nomes dos arquivos e os metadados do inode, como as permissões, pertencem a uma camada separada. Ainda não entendi que vantagem isso oferece. Parece ser mais uma maneira de fornecer diferentes botões de desempenho para objetos equivalentes a arquivos quando usados para armazenar sistemas de arquivos aninhados.
Além disso, os usuários geralmente não conseguem abrir arquivos pelo número do inode. Se pudessem, você não seria capaz de controlar o acesso a um arquivo através das permissões do diretório que o contém{y,ies}...
Talvez outra maneira de ver o último ponto seja que ele é um recurso dos diretórios. Todo o princípio de um diretório é mapear nomes de arquivos, portanto, sem isso eles não terão nenhum efeito.
Espere, você diz, eles ainda teriam um efeito como um contêiner para referências a arquivos, também conhecidos como "links físicos". Você pode ter arquivos listados em vários diretórios; remover um arquivo de um diretório ( unlink) na verdade não o exclui, se ele ainda permanecer em outro diretório. Hard links são uma parte interessante da implementação unix, mas AFAIK eles nunca encontraram nenhuma utilidade! Geralmente são considerados apenas como uma oportunidade para confusão. Um exemplo de exposição de um detalhe de implementação porque tornou muito fácil fornecer recursos interessantes, sem realmente considerar se o recurso era necessário. Semelhante ao “erro de um bilhão de dólares”, embora essa falha de projeto específica não tenha sido tão perigosa.
Dito isto, vale a pena observar a forma como os diretórios garantem a existência dos arquivos que contêm. Se você quisesse implementar algum outro sistema para identificar arquivos, você teria que considerar a possibilidade de que a exclusão de um arquivo deixaria você com uma entrada referente a um arquivo inexistente, ou mesmo a um arquivo novo e não relacionado ao qual foi atribuído o mesmo inode número mais tarde.