Chaque fichier ou répertoire nécessite un inode, et le nom de l'objet se trouve dans un répertoire plutôt que dans l'inode lui-même. Les opérations courantes sur les métadonnées, telles que la création, la recherche, la récupération d'attributs, le renommage, l'énumération et la suppression de fichiers, peuvent dominer une charge de travail comportant un grand nombre de fichiers, même lorsque le débit de données est faible. Dans ces scénarios, le taux d'utilisation du processeur, le traitement séquentiel des opérations et le RTT réseau peuvent devenir des goulots d'étranglement pour les performances. Le comportement du protocole est également important : les clients NFS et SMB peuvent émettre différentes combinaisons d'opérations de recherche, d'ouverture, de fermeture, d'attribut et de lecture de répertoire, qui dépendent souvent de la version du protocole. Par conséquent, des résultats différents pour des workflows similaires impliquant un grand nombre de fichiers peuvent être observés selon le protocole et la version du protocole utilisés.

ONTAP stocke les inodes publics dans un fichier d'inodes caché, géré par le système, au niveau du volume. Chaque inode ONTAP 9 utilise 288 octets, de sorte que le fichier d'inodes lui-même consomme de la capacité utilisable dans le volume. Un million d'inodes publics alloués utilisent environ 288 Mo. La suppression d'objets libère des inodes pour leur réutilisation, mais le fichier d'inodes ne rétrécit pas.

De plus, les fichiers de répertoire consomment de la capacité lorsqu'un grand nombre de noms sont stockés dans un même répertoire. Ces fichiers de répertoire ne font pas partie du fichier d'inodes. Ils stockent les noms et les correspondances avec les numéros d'inodes, et maxdir-size limitent chacun d'eux indépendamment. Le paramètre par défaut de 320 Mo est une limite, et non une réservation ; si un fichier de répertoire atteint 320 Mo de blocs de fichier de répertoire, ces blocs utilisent 320 Mo de la capacité réelle du volume.

Ces deux structures peuvent s'accumuler. Avec un nombre élevé d'inodes alloués, le fichier inode seul peut atteindre plusieurs Go, et un ou plusieurs fichiers de répertoire volumineux peuvent ajouter des centaines de mégaoctets en plus. Un volume peut également avoir un fichier inode volumineux alors que la taille de chaque répertoire reste faible, ou un répertoire volumineux avec un fichier inode encore petit. Ces métadonnées consomment de la capacité utilisée du volume, ce qu'il est facile de manquer si vous ne consultez que les listes côté client des fichiers de données utilisateur. Le fichier inode n'est pas un fichier visible par l'utilisateur ; la taille du fichier de répertoire est visible sur l'objet répertoire lui-même.

L'énumération des grands répertoires prend plus de temps que celle des petits, et l'analyse d'un répertoire dont de nombreux fichiers ont été supprimés peut s'avérer coûteuse. La taille du fichier de répertoire signalée reste à son niveau maximal même après la suppression de noms. La perforation sur les répertoires indexés permet de récupérer les blocs physiques vides et de les ignorer lors de READDIR, mais elle ne réduit généralement pas la taille signalée ; voir "Comportement de la limite maxdir-size" et "Répertoires clairsemés et perforation de trous".

Le regroupement de millions d'entrées dans un seul répertoire crée un point unique de mise à l'échelle et de sérialisation du répertoire, ce qui peut impacter les performances non seulement du répertoire lui-même, mais aussi du nœud (ou du volume) qui possède le répertoire. La distribution des fichiers sur une hiérarchie à plusieurs répertoires améliore le parallélisme, réduit la portée des analyses de répertoires et simplifie les tâches opérationnelles.

Un grand nombre d'objets peut allonger les analyses d'espace de noms, le catalogage des sauvegardes, la réplication, le traitement de restauration et la création de l'index de répertoire après restauration. Par exemple, NetApp SnapMirror réplique les métadonnées modifiées ainsi que les données de fichier, de sorte qu'une référence ou une mise à jour avec de nombreuses créations, suppressions ou opérations de renommage peut s'avérer coûteuse, même lorsque le nombre de fichiers et l'empreinte de capacité sont faibles. Ces difficultés peuvent également s'étendre aux sauvegardes basées sur NDMP.

Pour plus d'informations sur le transfert d'index de répertoire avec SnapMirror, voir "Indexation des répertoires dans ONTAP".

maxfiles (configuré comme l'option au niveau du volume -files) constitue une limite configurable pour le nombre d'inodes publics disponibles dans un seul volume. Ce nombre inclut non seulement les fichiers et les répertoires, mais aussi les flux nommés, les listes de contrôle d'accès (ACL) et d'autres objets publics, parfois des objets qui ne sont pas visibles dans une liste de répertoires classique. Le volume contient un fichier d'inodes masqué qui contient ces enregistrements. ONTAP agrandit le fichier d'inodes lorsqu'un nouvel inode public est nécessaire et qu'il ne reste aucun enregistrement libre, jusqu'au paramètre -files et à la taille totale du volume. Le maximum configurable pour -files dépend de la taille du volume et des limites d'ONTAP.