Por que a tabela de inodes geralmente não é redimensionável?

Question

Os sistemas de arquivos Unix geralmente possuem uma tabela de inode, e o número de entradas nesta tabela é geralmente fixo no momento em que o sistema de arquivos é criado. Isso às vezes leva pessoas com muito espaço em disco a confundirem mensagens de erro sobre o espaço livre, e mesmo depois de descobrirem qual é o problema, não há uma solução fácil para o que fazer a respeito.

Mas parece (para mim) que seria muito desejável evitar toda essa confusão alocando inodes sob demanda, de forma completamente transparente para usuários e administradores de sistema. Se você gosta de hacks bonitinhos, você pode até mesmo tornar a própria tabela de inode um arquivo e, assim, reutilizar o código que você já possui e encontrar espaço livre no disco. Se você tiver sorte, pode até acabar com os inodes próximos aos arquivos, sem tentar explicitamente atingir esse resultado.

Mas ninguém (que eu saiba) realmente faz isso, então provavelmente há uma pegadinha que estou perdendo. Alguma idéia do que poderia ser?

    

Answer 1

Digamos que você fez da tabela de inodes um arquivo; então a próxima pergunta é ... onde você armazena informações sobre esse arquivo? Assim, você precisaria de inodes "reais" e inodes "estendidos", como uma tabela de partições do MS-DOS. Dado, você precisaria apenas de um (ou talvez de alguns - por exemplo, para que seu diário também fosse um arquivo). Mas você realmente tem casos especiais, código diferente. Qualquer corrupção nesse arquivo também seria desastrosa. E considere que, antes do registro no diário, era comum os arquivos que estavam sendo escritos, por exemplo, quando a energia elétrica estava muito danificada. As operações do seu arquivo teriam que ser um lote mais robusto vs. falha de energia / travamento / etc. do que estavam em, por exemplo, ext2.

Sistemas de arquivos Unix tradicionais encontraram uma solução mais simples (e mais robusta): colocar um bloco de inode (ou grupo de blocos) a cada bloco X. Então você os encontra por simples aritmética. Claro, então não é possível adicionar mais (sem reestruturar todo o sistema de arquivos). E mesmo se você perder / corromper o bloco de inode que você estava escrevendo quando a energia falhou, isso é apenas perder alguns inodes - muito melhor do que uma parte substancial do sistema de arquivos.

Designs mais modernos usam coisas como as variantes B-tree . Sistemas de arquivos modernos como o btrfs, o XFS e o ZFS não sofrem com os limites do inode.

    

Answer 2

Muitos sistemas de arquivos têm uma tabela de inodes dinamicamente alocáveis (ou seu equivalente moral) (XFS, BTRFS, ZFS, VxFS ...)

O Unix UFS original tinha inodes que foram corrigidos no tempo de criação do sistema de arquivos e sistemas de arquivos derivados dele (Linux EXT, Solaris UFS) frequentemente continuavam o esquema. É robusto e simples de implementar. Tantos casos de uso são bons, que projetar um novo sistema de arquivos apenas para evitar que um problema não seja fácil de justificar.

    

Answer 3

Existem sistemas de arquivos que alocam inodes dinamicamente: pelo menos na minha cabeça, pelo menos Veritas VxFS (= o sistema de arquivos padrão do HP-UX e uma das opções disponíveis no Solaris) e XFS (o tipo de sistema padrão no RHEL 7) trabalhe assim. Btrfs e JFS da IBM também.