Pourquoi un grand nombre de fichiers épuise-t-il les inodes d'un NAS domestique avant l'espace disque ?

Un nombre élevé de fichiers peut épuiser l'approvisionnement en inodes d'un NAS domestique avant d'épuiser les blocs de données. Le résultat semble contradictoire : un écran de capacité peut afficher des gigaoctets ou téraoctets libres, mais une opération de téléchargement, de sauvegarde, de conteneur ou d'indexation ne peut plus créer un autre fichier.

C'est une limite du système de fichiers, pas une propriété universelle de tous les NAS. L'échec classique est le plus facile à voir sur ext4 et les systèmes de fichiers similaires avec une population d'inodes définie, tandis que XFS et Btrfs allouent les métadonnées différemment. Le type de système de fichiers détermine donc si « inodes libres » est la bonne métrique ou seulement une partie du diagnostic.

Un NAS domestique peut épuiser les emplacements d'objets avant les blocs de données

La cause directe est que les données du fichier et l'identité du fichier consomment des ressources différentes. Dans ext4, un inode enregistre des métadonnées telles que les horodatages, la propriété, les mappages de blocs et les attributs étendus, tandis qu'une entrée de répertoire associe un nom à un inode. La documentation des inodes ext4 du noyau Linux décrit sa table d'inodes comme un tableau linéaire réparti dans les groupes de blocs.

Chaque nouveau fichier régulier nécessite normalement un inode, mais la taille en octets ne détermine pas combien d'inodes il faut. Une vidéo de 100 Go peut occuper un seul inode, tandis qu'un million de petits fichiers cache peuvent nécessiter environ un million d'inodes. Les répertoires et les liens symboliques sont aussi des objets du système de fichiers, tandis que plusieurs liens physiques vers le même fichier partagent un inode.

Des blocs libres peuvent donc rester disponibles après que le dernier inode libre a été attribué. À ce stade, le NAS a encore de la place pour plus de contenu de fichiers en principe, mais il manque l'identité des métadonnées nécessaire pour créer un autre objet. La capacité et le nombre d'objets sont suffisamment indépendants pour que les deux doivent être surveillés.

Pourquoi les petits fichiers épuisent les inodes plus vite que la capacité

Les petits fichiers créent une forte densité d'objets : de nombreuses identités sont nécessaires pour une charge utile relativement faible. Un fichier de taille zéro nécessite toujours des métadonnées, et un arbre de répertoires ajoute ses propres inodes de répertoire avant même que les fichiers qu'il contient ne soient comptés. C'est pourquoi une charge de travail peut consommer les emplacements de fichiers beaucoup plus rapidement qu'elle ne consomme les téraoctets annoncés d'un NAS.

Sur ext4, l’outil de création peut calculer la population d’inodes à partir d’un ratio octets par inode ou accepter un nombre explicite d’inodes. Les options d’allocation d’inodes mke2fs indiquent qu’un ratio octets par inode plus grand crée moins d’inodes et que ce ratio ne peut pas être modifié après la création du système de fichiers, bien que le redimensionnement maintienne le ratio configuré en ajoutant des inodes avec l’espace nouveau.

Un modèle simple de planification est population approximative d’inodes = taille du système de fichiers ÷ ratio octets par inode. Avec un ratio hypothétique de 16 KiB, 1 TiB correspond à environ 67 millions de slots d’inodes avant de considérer les frais de formatage et les limites du système de fichiers. C’est une illustration, pas une valeur par défaut universelle pour NAS : les profils de formatage et les implémentations de systèmes de fichiers choisissent des politiques différentes.

Ce qui change lorsque le dernier inode libre est alloué

Dans le cas classique d’épuisement, les opérations nécessitant un nouvel inode commencent à échouer. Les nouveaux téléchargements, répertoires, fichiers temporaires, membres d’archives extraits et fichiers d’état d’application peuvent tous être rejetés même si les fichiers existants peuvent encore être lus. Un fichier existant peut aussi pouvoir s’agrandir si des blocs de données libres restent car il possède déjà un inode.

Les applications traduisent souvent l’échec d’allocation par un message générique « Plus d’espace disponible sur le périphérique ». Ce message identifie une allocation de ressource échouée, mais il n’indique pas à l’utilisateur si la ressource manquante était des blocs de données, des inodes, une allocation de quota ou un espace de métadonnées spécifique au système de fichiers. L’erreur visible doit être associée à des compteurs du système de fichiers.

Quelles charges de travail NAS domestiques créent un nombre extrême de fichiers

La charge de travail risquée n’est pas simplement une « grande quantité de données ». C’est toute charge de travail qui matérialise de nombreux objets indépendants du système de fichiers, surtout lorsque le nettoyage ou la rétention permet à ces objets de s’accumuler pendant des mois.

Couches de conteneurs, journaux et arbres de paquets

Les images de conteneurs, les paquets logiciels extraits, les arbres de dépendances, les journaux rotatifs et les caches d’applications peuvent placer un grand nombre de petits objets sous un service hébergé sur NAS. L’image du conteneur peut sembler modeste en gigaoctets tandis que ses couches décompressées et son état modifiable consomment bien plus d’identités d’objets qu’un fichier média de même taille.

Vignettes photo et index de recherche

Un gestionnaire de photos peut générer des vignettes, des aperçus, des fichiers annexes, des recadrages de visages ou des fragments d’index pour chaque élément source. Certaines applications consolident ces enregistrements dans des bases de données, tandis que d’autres en stockent beaucoup sous forme de fichiers ordinaires, de sorte que l’effet inode dépend de la conception du stockage de l’application plutôt que de la seule taille de la bibliothèque photo.

Synchroniser les historiques, les arbres de sauvegarde et les magasins de mails

Les systèmes de versionnage qui matérialisent les révisions sous forme de fichiers, les arbres de sauvegarde contenant de nombreux objets source, et les magasins de mails un message par fichier peuvent tous produire un nombre élevé de fichiers. Les instantanés copy-on-write et les dépôts dédupliqués peuvent représenter les versions différemment, donc un compte d'instantanés ne doit pas être traité comme un compte direct d'inodes sans vérifier l'implémentation.

Pourquoi un tableau de bord de capacité peut manquer la pression sur les inodes

De nombreux tableaux de bord mettent l'accent sur les octets : capacité totale, blocs utilisés et blocs libres. L'interface standard des statistiques du système de fichiers conserve séparément les compteurs d'objets comme total, libre et disponible pour les numéros de fichiers ; sous Linux, ceux-ci correspondent à des champs tels que f_files et f_ffree dans statvfs statistiques du système de fichiers. Une interface utilisateur qui omet ces champs peut sembler saine lors d'un épuisement classique des inodes.

Sur un NAS basé sur Linux avec accès shell, l'utilisation des blocs et des inodes peut être comparée pour le même chemin monté :

df -h /chemin/sur/nas  
df -i /chemin/sur/nas  

Le manuel GNU df définit -i comme l'utilisation des inodes au lieu de l'utilisation des blocs et affiche les champs total, utilisé, disponible et pourcentage. Des blocs libres avec zéro inode disponible soutiennent fortement l'épuisement classique des inodes ; une marge dans les deux colonnes indique une autre limite.

Les systèmes de fichiers à inodes fixes et dynamiques échouent différemment

« Le NAS a manqué d'inodes » est exact uniquement lorsque le modèle d'allocation du système de fichiers et les compteurs rapportés le confirment. Le même message d'absence d'espace peut provenir d'une autre limite de métadonnées sur un autre système de fichiers.

La politique d’espace inode XFS peut plafonner le pourcentage du système de fichiers alloué aux inodes, tandis que le rapport officiel du système de fichiers Btrfs sépare Données, Système, Métadonnées et RéserveGlobale. Ces modèles peuvent produire des limites liées aux métadonnées, mais ils ne doivent pas être expliqués comme si chaque NAS avait la même table d’inodes fixe.

L’interface statistique générique avertit également que tous les champs retournés ne sont pas significatifs sur tous les systèmes de fichiers. Identifiez d’abord le système de fichiers monté, puis interprétez df -i à travers cette implémentation au lieu de traiter une commande comme une preuve universelle.

Ce que signifie la marge d’inodes pour la planification de la capacité NAS

Une prévision de capacité pour une charge de travail à objets nombreux nécessite à la fois les octets attendus et le nombre d’objets attendu. Les archives médias sont généralement denses en octets, tandis que les arbres de dépendances, vignettes, boîtes mail et arbres de sauvegarde matérialisés peuvent être denses en objets. Deux charges de travail de même taille logique peuvent donc nécessiter des marges de métadonnées très différentes.

Pour un volume ext4, le ratio octets par inode est un choix de conception au moment du formatage plutôt qu’un réglage dynamique habituel. Le redimensionnement peut ajouter des inodes selon le ratio établi, mais ne modifie pas rétroactivement ce profil de densité. Reformater uniquement pour changer ce ratio est une décision de migration avec des conséquences de sauvegarde et restauration, pas un ajustement de performance anodin.

Une fois la pression sur les inodes écartée, les questions ordinaires de capacité en blocs restent distinctes ; un plan de capacité de stockage NAS à domicile peut compléter cette décision, mais les conseils sur les téraoctets libres ne remplacent pas un décompte des inodes ou des métadonnées.

Pourquoi la suppression d’un seul gros fichier peut ne pas libérer suffisamment d’inodes

Supprimer un grand film peut libérer de nombreux blocs de données mais libère normalement un seul inode. Supprimer un arbre de répertoires contenant des centaines de milliers d’objets cache jetables peut libérer de nombreux inodes même lorsque la capacité de récupération en octets est relativement faible. Le nettoyage doit correspondre à la ressource épuisée.

Un objet désindexé n'est pas toujours récupéré immédiatement. Le comportement unlink de Linux maintient un fichier en existence lorsqu'un processus a encore son dernier lien ouvert, et le libère après la fermeture du dernier descripteur de fichier référent. La récupération des inodes peut donc être retardée par rapport à la suppression du chemin pour les journaux actifs ou les fichiers de service.

FAQ

Chaque fichier utilise-t-il exactement un inode ?

Un fichier ordinaire possède normalement un inode, et les répertoires ainsi que les liens symboliques ont aussi leur propre identité dans le système de fichiers. Plusieurs noms de liens physiques peuvent pointer vers le même inode, tandis que des fonctionnalités spécifiques au système de fichiers peuvent stocker des métadonnées supplémentaires dans des objets séparés, donc le nombre de chemins et le nombre d'inodes sont liés mais pas toujours identiques.

Un cache SSD ou un réseau plus rapide peut-il empêcher l'épuisement des inodes ?

Non. Des médias plus rapides et un réseau plus performant peuvent réduire la latence ou augmenter le débit, mais ils ne créent pas de nouveaux emplacements d'inodes dans une population d'inodes fixe. Ils peuvent faire en sorte qu'une charge de travail avec un grand nombre de fichiers s'exécute plus rapidement et atteigne plus tôt la même limite de métadonnées.

Est-ce que df -i fonctionne sur tous les systèmes de fichiers NAS domestiques ?

Il rapporte les compteurs de type inode fournis via l'interface du système de fichiers monté, mais ces compteurs peuvent ne pas avoir la même signification sur tous les systèmes de fichiers. Utilisez-le directement pour un diagnostic de type ext4 et associez-le à des outils de métadonnées spécifiques au système de fichiers pour XFS, Btrfs, ZFS, ou un appareil qui abstrait le volume sous-jacent.

L'extension d'un système de fichiers ext4 peut-elle ajouter plus d'inodes ?

Oui, le redimensionnement ext4 peut ajouter des inodes lorsque de l'espace supplémentaire est incorporé tout en maintenant le ratio octets par inode existant. Cela diffère du changement de ce ratio sur le système de fichiers existant, ce que la documentation de l'outil de création indique comme non supporté après le formatage.

Est-ce que chaque erreur « Plus d'espace disponible sur le périphérique » est causée par les inodes ?

Non. Des blocs de données pleins, des quotas, de l'espace réservé, l'allocation des métadonnées Btrfs, des limites d'espace temporaire et certaines limites de ressources non liées au stockage peuvent produire des messages similaires. L'épuisement des inodes est pris en charge lorsque l'échec concerne la création d'objets du système de fichiers et que le compteur d'inodes pertinent n'a plus d'entrées disponibles.

Le nombre de fichiers est une dimension de capacité à part entière

Un NAS domestique peut conserver de l'espace disque libre tout en cessant d'accepter de nouveaux objets parce que les octets et les métadonnées du système de fichiers sont des dimensions de capacité distinctes. Considérez un nombre élevé de fichiers comme une propriété de la charge de travail, confirmez le système de fichiers réel, et comparez la marge de manœuvre des blocs avec celle des inodes ou des métadonnées avant de conclure que les disques sont pleins.