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?

filesystems inode

— Mark VY
source

Vous venez de réinventer le répertoire des fichiers maîtres et l'index des fichiers-11 dans VMS, le précurseur de la table des fichiers maîtres dans NTFS.

— JdeBP

J'ai réinventé le précurseur de la MFT? Cool!

— Mark VY

Réponses:

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.

— derobert
source

Lorsque vous dites "ne souffrez pas des limites d'inode", cela signifie-t-il que de nouveaux inodes sont alloués complètement en arrière-plan, ou quelqu'un doit-il exécuter une commande comme "expand-table-now-please"?

— Mark VY

@MarkVY complètement dans les coulisses (si les inodes sont vraiment utilisés).

— derobert

D'accord, donc mes connaissances sont loin derrière les temps apparemment. Merci pour la réponse détaillée. Je n'ai jamais pensé à ce qui se passerait en cas de panne de courant ou similaire. Donc, mon hack mignon est assez dangereux à moins que "ajouter au fichier" soit déjà une opération atomique dans le système de fichiers. Ce qui, selon vous, était assez rare dans le passé.

— Mark VY

Je me souviens que XFS et btrfs souffraient très occasionnellement d'une légère corruption du système de fichiers - zfs aussi? Ce n'est pas un risque pour certains, mais cela pourrait être un risque pour des données importantes et le coût de l'allocation dynamique. Pour XFS dans cette boutique, son problème révolutionnaire était une incapacité totale à réduire un système de fichiers par tous les moyens.

— user2066657

Btrfs ne souffre peut-être pas de limites d'inode, mais il souffre d'une erreur complètement différente qui provoque des symptômes tout aussi confus (en gros, il manque d'espace de métadonnées tout en ayant beaucoup d'espace de données disponible, en raison d'une utilisation inefficace des groupes de blocs). Cela entraîne non seulement le signalement d'erreurs de disque saturé lorsque des dfrapports indiquent qu'il y a beaucoup d'espace disponible, mais il ne peut pas être corrigé en supprimant des fichiers car la suppression d'un fichier nécessite d'allouer de l'espace de métadonnées.

— Mark

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.

— BowlOfRed
source

Cependant, beaucoup de progrès dans l'informatique ont été réalisés par des personnes qui résolvent des problèmes difficiles à justifier.

— user253751

Mais aussi, beaucoup de progrès dans les solutions pas faciles à résoudre :) Les premiers systèmes de fichiers «complexes» - NTFS NTFS, reiserfs - avaient un moyen d'échouer de façon catastrophique QUAND ils échouaient ....

— rackandboneman

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.

— telcoM
source