Projeto do sistema de arquivos: necessidade do número de inode e da tabela [closed]

Question

Os sistemas de arquivos * nix mantêm uma tabela de inode no início do disco (ou em algum local fixo). Ele é indexado pelo número do inode, que é um inteiro que identifica exclusivamente um inode. Sabendo o número do inode, um inode pode ser encontrado rapidamente. O inode contém ponteiros / endereços para outros blocos de disco, que contém os dados reais do arquivo.

Eu gostaria de saber se a minha abordagem abaixo para se livrar da tabela de inode e o número de inode é eficiente:

Ainda temos inodes, mas agora, os inodes são armazenados na região de dados do disco e, em vez de rastrear o número do inode, apenas gravamos o endereço do disco ou o número do bloco do inode. Sempre que tentamos acessar um arquivo ou seu inode, apenas usamos o endereço do disco para encontrar o inode, em vez de indexar na tabela do inode usando o número do inode. Isso nos salvará de outra camada de indireção.

O que está faltando na minha abordagem? Eu gostaria de entender o raciocínio por trás da tabela de inodes.

    

Answer 1

Se eu entendi corretamente, você deseja substituir o número do inode pelo endereço do bloco. Isso significa (1) um inode por bloco, o que desperdiça muito espaço (o inode não é tão grande), e (2) não é tão diferente de usar um número inode: um inode tem um tamanho fixo, então um bloco contém um número conhecido n de inodes. Então, se você deduzir o número de inode por n (que idealmente é uma potência de dois, então é apenas uma mudança), o quociente é o número do bloco do inode (mais o endereço do disco onde a tabela de inode é iniciada) e restante é o índice do inode dentro desse bloco.

Para entender a lógica por trás da tabela de inode, pense em quais dados são armazenados na tabela de inodes: são atributos como proprietário, grupo, permissões e registros de data e hora, e índices e índices indiretos dos blocos de dados. Você precisa armazená-los em algum lugar e não pode armazená-los juntos com os dados do arquivo.

Então, se você quer projetar seu próprio sistema de arquivos, a primeira pergunta que você deve responder é "como eu identifico os blocos de dados que pertencem a um arquivo?" e a segunda pergunta é "onde eu armazeno atributos como propriedade, permissões e timestamps?". E sim, você pode usar esquemas diferentes para isso do que inodes.

Editar

Quanto a

why not just use its address, like we do with main memory and objects therein?

Como escrevi, basicamente você tem o endereço do bloco - você só precisa dividir primeiro e adicionar um deslocamento. Se você adicionar o offset a cada inode em princípio, o "inode number" será muito maior, e você terá um valor constante nos bits altos que é repetido em cada número de inode. Isso, por sua vez, tornará cada entrada de diretório maior.

Não se esqueça que o sistema de arquivos unix foi inventado quando o tamanho do disco rígido era de cerca de 20 Mbytes ou mais. Você não quer perder espaço, então você embala tudo densamente e evita a redundância. Adicionar um offset toda vez que você acessar um inode é barato. Armazenar este offset como parte de toda referência do "número inode" é caro.

E o interessante é que, embora o esquema de inode tenha sido inventado para pequenos discos rígidos em termos atuais, ele se adapta bem e até mesmo em discos rígidos no intervalo de terabytes em "apenas funciona".