Lorsqu'un fichier ou un répertoire possède un descripteur de sécurité NTFS ou une ACL NFSv4, ONTAP stocke cette ACL dans un inode ACL distinct (également appelé inode étendu ou xinode). L'inode ACL contient les ACE. ONTAP l'alloue à partir de l'espace d'inodes public, il est donc comptabilisé dans files et files-used. L'inode du fichier ou du répertoire référence son inode ACL.

L'utilisation d'un inode ACL ne correspond pas toujours à une relation 1:1 avec un fichier ou un répertoire :

Un flux nommé correspond à des données supplémentaires associées à un fichier, en plus du contenu que les utilisateurs ouvrent normalement. Dans ONTAP, il s'agit de la représentation WAFL d'un flux de données alternatif NTFS (ADS). Les données par défaut du fichier, non nommées, résident dans l'inode de base du fichier. Chaque flux nommé supplémentaire correspond à un inode public distinct et compte dans files et files-used.

Les flux nommés persistent avec le fichier. Il ne s'agit pas d'une zone de travail temporaire que ONTAP utilise uniquement lors de l'ouverture, de la copie ou de l'enregistrement. Un flux reste alloué jusqu'à ce que ce flux soit supprimé ou que le fichier de base soit supprimé. Une application peut créer un flux puis le supprimer, mais ONTAP n'expire pas les flux nommés de lui-même.

Quelques points à noter :

Lors du traitement de vidage et de restauration NDMP, ONTAP identifie séparément les classes d'objets telles que les fichiers ordinaires, les répertoires, les flux NT, les répertoires de flux et les inodes ACL afin que les données et les métadonnées de chaque objet puissent être sérialisées, consignées dans les statistiques de vidage et reconstruites correctement. Cette classification ne crée pas de limites maxfiles distinctes ni de compteurs séparés volume show. files-used Le total combiné des inodes publics demeure.

La commande NDMP dump parcourt l'espace de noms et sérialise ces objets un par un. La restauration les reconstruit de la même manière. Un nombre élevé d'inodes publics allonge donc la durée du dump et de la restauration, même si la capacité de données du volume est modeste ou que le nombre de fichiers visibles semble faible. Les flux nommés et les inodes ACL sont vidés et restaurés même si l'Explorateur Windows, le Finder dir, ou ls ne les affichent pas, de sorte que les statistiques du dump peuvent indiquer un plus grand nombre d'objets de flux et d'ACL que ne le suggère une simple liste de répertoires.

Le traitement est souvent limité par les métadonnées plutôt que par le débit. La création, la recherche et la reconstruction de millions d'inodes, de listes de contrôle d'accès (ACL) et de flux consomment des ressources CPU, mémoire et d'E/S de stockage, avec relativement peu de données par objet. Les petits fichiers, l'utilisation intensive des ACL et les nombreux flux nommés augmentent cette surcharge. Les grands répertoires plats ajoutent un coût d'énumération lors de la sauvegarde, et la restauration d'un volume contenant un grand nombre de fichiers peut également prendre du temps pour reconstruire les index de répertoire une fois les objets restaurés. Mesurez la durée de la sauvegarde et de la restauration avec un nombre d'objets représentatif, y compris les flux et les ACL, plutôt que de l'estimer à partir de la seule taille des données.

Un fichier non lié ne peut pas toujours être libéré immédiatement. ONTAP peut le conserver temporairement comme zombie pendant la finalisation des références ou des opérations asynchrones. Les opérations de suppression asynchrones importantes peuvent donc augmenter l'utilisation des inodes privés pendant le nettoyage. Là encore, les inodes privés ne sont pas comptabilisés dans le total files autorisé sur le volume.