Os sistemas de arquivos Unix geralmente possuem uma tabela inode, e o número de entradas nessa tabela geralmente é fixado no momento em que o sistema de arquivos é criado. Às vezes, isso leva as pessoas com muito espaço em disco a receberem mensagens de erro confusas sobre a 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 a respeito.
Mas parece (para mim) que seria muito desejável evitar toda essa confusão alocando inodes sob demanda, de forma totalmente transparente para usuários e administradores de sistema. Se você gosta de truques fofos, pode até transformar a própria tabela inode em um arquivo e, assim, reutilizar o código que já possui e que encontra espaço livre no disco. Se você tiver sorte, pode até acabar com os inodes próximos aos próprios arquivos, sem tentar explicitamente obter esse resultado.
Mas ninguém (que eu saiba) realmente faz isso, então provavelmente há um problema que estou perdendo. Alguma ideia do que pode ser?
Digamos que você transformou a tabela inode em um arquivo; então a próxima pergunta é... onde você armazena informações sobre esse arquivo? Portanto, você precisaria de inodes "reais" e inodes "estendidos", como uma tabela de partições do MS-DOS. Dado, você só precisaria de um (ou talvez alguns - por exemplo, para também ter seu diário como um arquivo). Mas você realmente teria casos especiais, códigos diferentes. Qualquer corrupção nesse arquivo também seria desastrosa. E considere que, antes do registro no diário, era comum que os arquivos que estavam sendo gravados, por exemplo, quando faltava energia, fossem fortemente danificados. Suas operações de arquivo teriam que ser muito mais robustas versus falha de energia/crash/etc. do que eles estavam, por exemplo, ext2.
Os sistemas de arquivos Unix tradicionais encontraram uma solução mais simples (e mais robusta): coloque um bloco inode (ou grupo de blocos) a cada X blocos. Então você os encontra por aritmética simples. Claro, então não é possível adicionar mais (sem reestruturar todo o sistema de arquivos). E mesmo se você perder/corromper o bloco inode no qual estava gravando quando a energia falhou, isso significa perder 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 com limites de inode.
Muitos sistemas de arquivos possuem uma tabela de inodes dinamicamente alocável (ou seu equivalente moral) (XFS, BTRFS, ZFS, VxFS...)
O Unix UFS original, entretanto, tinha inodes que eram corrigidos no momento da criação do sistema de arquivos e sistemas de arquivos derivados dele (Linux EXT, Solaris UFS) muitas vezes continuavam 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 esse problema não é fácil de justificar.
Existem sistemas de arquivos que alocam inodes dinamicamente: de cara, 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 de arquivos padrão no RHEL 7) funcionam dessa maneira. Btrfs e JFS da IBM também.