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

Os sistemas de arquivos Unix geralmente têm uma tabela de inode, e o número de entradas nesta tabela é geralmente fixo no momento em que o sistema de arquivos é criado. Às vezes, isso leva as pessoas com muito espaço em disco a receber mensagens de erro confusas sobre falta de espaço livre e, mesmo depois de descobrirem qual é o problema, não há uma solução fácil para o que fazer.

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

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

filesystems inode

— Mark VY
fonte

Você acabou de reinventar o Diretório de Arquivos Principais e o Índice de Arquivos-11 no VMS, o precursor da Tabela de Arquivos Principais no NTFS.

— JdeBP # 06/18

Reinventei o precursor da MFT? Legal!

— Mark VY

Respostas:

Digamos que você transformou a tabela de inodes em um arquivo; então a próxima pergunta é ... onde você armazena informações sobre esse arquivo? Assim, você precisaria de inodes "reais" e de inodes "estendidos", como uma tabela de partição do MS-DOS. Dado, você precisaria apenas de um (ou talvez alguns - por exemplo, para que seu diário também seja um arquivo). Mas você teria 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 gravados, por exemplo, quando a energia acabava danificada. Suas operações de arquivo teriam que ser muito mais robustas vs. falta de energia / falha / etc. do que eles estavam, por exemplo, ext2.

Os 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 aritmética simples. Obviamente, não é possível adicionar mais (sem reestruturar todo o sistema de arquivos). E mesmo que você perca / corrompa o bloco de inodes para o qual estava gravando quando a energia falhou, isso está perdendo apenas alguns inodes - muito melhor do que uma parte substancial do sistema de arquivos.

Projetos mais modernos usam coisas como variantes de árvore B. Sistemas de arquivos modernos como btrfs, XFS e ZFS não sofrem limites de inode.

— derobert
fonte

Quando você diz "não sofre limites de inode", isso significa que novos inodes são alocados completamente nos bastidores, ou alguém precisa executar um comando como "expand-table-now-please"?

— Mark VY

@ MarkVY completamente nos bastidores (se inodes são realmente usados).

— derobert

Ok, então meu conhecimento está bem atrás dos tempos, aparentemente. Obrigado pela resposta detalhada. Eu nunca pensei sobre o que aconteceria no caso de perda de energia ou similar. Portanto, meu hack bonito é bastante perigoso, a menos que "acrescentar ao arquivo" já seja uma operação atômica no sistema de arquivos. O que você afirma ser bastante raro nos tempos antigos.

— Mark VY

Lembro-me de XFS e Btrfs muito ocasionalmente sofrem de corrupção de arquivos leve - zfs também? Não é um risco para alguns, mas pode ser um risco para dados importantes e o custo da alocação dinâmica. Para o XFS nesta loja, seu problema de quebra de negócio era uma total incapacidade de reduzir um sistema de arquivos por qualquer meio.

— user2066657

O Btrfs pode não sofrer limites de inode, mas sofre de uma falha completamente diferente que causa sintomas igualmente confusos (basicamente, fica sem espaço de metadados e ainda possui bastante espaço de dados disponível, devido ao uso ineficiente de grupos de blocos). Isso não apenas faz com que ele relate erros de disco cheio quando dfrelata bastante espaço disponível, como também não pode ser corrigido com a exclusão de arquivos, pois a exclusão de um arquivo requer a alocação de espaço de metadados.

— Mark

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

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

— BowlOfRed
fonte

Tanto progresso na computação foi feito por pessoas que resolvem problemas que não são fáceis de justificar.

— user253751

Mas também, muito progresso em soluções não fáceis de resolver :) Os primeiros sistemas de arquivos "complexos" - NTFS da era NT, reiserfs - tinham uma maneira de falhar catastroficamente QUANDO falhavam ...

— #

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

— telcoM
fonte