Pourquoi la table d'inode n'est-elle généralement pas redimensionnable?

Les systèmes de fichiers Unix ont généralement une table inode et le nombre d'entrées dans cette table est généralement fixé au moment de la création du système de fichiers. Cela conduit parfois des personnes disposant de beaucoup d'espace disque à recevoir des messages d'erreur déroutants sur l'absence d'espace libre, et même après avoir découvert le problème, il n'y a pas de solution facile pour savoir quoi faire.

Mais il me semble (il me semble) qu'il serait très souhaitable d'éviter tout ce gâchis en allouant des inodes à la demande, en toute transparence aux utilisateurs et aux administrateurs système. Si vous aimez les hacks mignons, vous pouvez même faire de la table inode elle-même un fichier, et ainsi réutiliser le code que vous avez déjà et qui trouve de l'espace libre sur le disque. Si vous êtes chanceux, vous pourriez même vous retrouver avec les inodes près des fichiers eux-mêmes, sans essayer explicitement d'obtenir ce résultat.

Mais personne (à ma connaissance) ne fait cela, donc il y a probablement un hic qui me manque. Une idée de ce que ça pourrait être?

Disons que vous avez fait de la table inode un fichier; alors la question suivante est ... où stockez-vous les informations sur ce fichier? Vous auriez donc besoin d'inodes "réels" et d'inodes "étendus", comme une table de partition MS-DOS. Étant donné, vous n'en aurez besoin que d'un (ou peut-être de quelques-uns - par exemple, pour que votre journal soit également un fichier). Mais vous auriez en fait des cas spéciaux, un code différent. Toute corruption de ce fichier serait également désastreuse. Et considérez qu'avant la journalisation, il était courant que des fichiers en cours d'écriture, par exemple, lorsque le courant s'éteigne soient fortement endommagés. Vos opérations sur les fichiers devraient être beaucoup plus robustes que les pannes de courant / crash / etc. qu'ils ne l'étaient, par exemple, ext2.

Les systèmes de fichiers Unix traditionnels ont trouvé une solution plus simple (et plus robuste): mettre un bloc inode (ou groupe de blocs) tous les X blocs. Ensuite, vous les trouvez par simple arithmétique. Bien sûr, il n'est pas possible d'en ajouter plus (sans restructurer l'ensemble du système de fichiers). Et même si vous perdez / corrompez le bloc inode sur lequel vous écriviez lorsque l'alimentation est coupée, cela ne fait que perdre quelques inodes - bien mieux qu'une partie substantielle du système de fichiers.

Les conceptions plus modernes utilisent des choses comme les variantes de l' arbre B. Les systèmes de fichiers modernes comme btrfs, XFS et ZFS ne souffrent pas de limites d'inode.

De nombreux systèmes de fichiers ont une table d'inode dynamiquement allouable (ou son équivalent moral) (XFS, BTRFS, ZFS, VxFS ...)

L'UFS Unix d'origine avait cependant des inodes qui étaient corrigés au moment de la création du système de fichiers et les systèmes de fichiers qui en dérivaient (Linux EXT, Solaris UFS) continuaient souvent le schéma. Il est robuste et plus simple à mettre en œuvre. Tant de cas d'utilisation sont un bon choix, que la conception d'un nouveau système de fichiers juste pour éviter ce problème n'est pas facile à justifier.

Il existe des systèmes de fichiers qui allouent les inodes de manière dynamique: du haut de ma tête, au moins Veritas VxFS (= le système de fichiers par défaut de HP-UX, et l'un des choix disponibles sur Solaris) et XFS (le type de système de fichiers standard sur RHEL 7) fonctionnent de cette façon. Btrfs et JFS d'IBM aussi.