Jede Datei oder jedes Verzeichnis benötigt einen Inode, und der Name des Objekts befindet sich in einem Verzeichnis, nicht im Inode selbst. Häufige Metadatenoperationen wie Dateierstellung, Suche, Attributabruf, Umbenennung, Aufzählung und Löschung können selbst bei geringem Datendurchsatz einen Workload mit einer hohen Anzahl von Dateien dominieren. In solchen Szenarien können CPU-Auslastung, serielle Verarbeitung von Operationen und die Netzwerk-RTT zu Leistungsengpässen werden. Auch das Protokollverhalten spielt eine Rolle: NFS- und SMB-Clients können unterschiedliche Kombinationen von Such-, Öffnungs-, Schließ-, Attribut- und Verzeichnisleseoperationen ausführen, die oft von der Protokollversion abhängen. Daher können bei ähnlichen Workflows mit einer hohen Anzahl von Dateien je nach verwendetem Protokoll und Protokollversion unterschiedliche Ergebnisse auftreten.

ONTAP speichert öffentliche Inodes in einer versteckten, systemverwalteten Inode-Datei auf Volume-Ebene. Jeder ONTAP 9 Inode belegt 288 Byte, sodass die Inode-Datei selbst nutzbare Kapazität im Volume beansprucht. Eine Million zugewiesener öffentlicher Inodes belegen etwa 288 MB. Das Löschen von Objekten gibt Inodes zur Wiederverwendung frei, die Inode-Datei selbst verkleinert sich jedoch nicht.

Zusätzlich belegen Verzeichnisdateien Kapazität, wenn viele Namen im selben Verzeichnis gespeichert werden. Diese Verzeichnisdateien sind nicht Teil der Inode-Datei. Sie speichern Namen und Zuordnungen zu Inode-Nummern und maxdir-size begrenzen jede Datei unabhängig. Die Standardeinstellung von 320 MB ist eine Obergrenze, keine Reservierung; wenn eine Verzeichnisdatei auf 320 MB an Verzeichnisdatei-Blöcken anwächst, belegen diese Blöcke 320 MB der tatsächlichen Volume-Kapazität.

Diese beiden Strukturen können sich summieren. Bei einer hohen Anzahl zugewiesener Inodes kann allein die Inode-Datei mehrere GB groß werden, und eine oder mehrere große Verzeichnisdateien können zusätzlich Hunderte von Megabyte belegen. Ein Volume kann auch eine große Inode-Datei haben, während alle Verzeichnisse weiterhin klein sind, oder ein großes Verzeichnis mit einer weiterhin kleinen Inode-Datei. Diese Metadaten belegen genutzte Volume-Kapazität, was leicht übersehen werden kann, wenn nur Client-seitige Auflistungen der Benutzerdatendateien betrachtet werden. Die Inode-Datei ist keine für den Benutzer sichtbare Datei; die Größe der Verzeichnisdatei ist am Verzeichnisobjekt selbst sichtbar.

Große Verzeichnisse benötigen länger zum Aufzählen als kleinere, und selbst ein Verzeichnis, aus dem viele Dateien gelöscht wurden, kann weiterhin aufwendig zu scannen sein. Die gemeldete Verzeichnisdateigröße bleibt auch nach dem Löschen von Namen auf ihrem Höchststand. Hole Punching in indizierten Verzeichnissen kann leere physische Blöcke freigeben und sie bei READDIR überspringen, aber die gemeldete Größe wird dadurch normalerweise nicht verringert; siehe "Wie sich die maxdir size Beschränkung verhält" und "Dünn besetzte Verzeichnisse und Hole Punching".

Die Konzentration von Millionen Einträgen in einem einzigen Verzeichnis erzeugt einen Skalierungs- und Serialisierungspunkt für ein einzelnes Verzeichnis, der die Leistung nicht nur des Verzeichnisses selbst, sondern auch des Knotens (oder Volumes), dem das Verzeichnis gehört, beeinträchtigen kann. Die Verteilung von Dateien über eine hierarchisch gegliederte Verzeichnisstruktur verbessert die Parallelität, reduziert den Umfang von Verzeichnisscans und vereinfacht operative Aufgaben.

Eine hohe Anzahl von Objekten kann Namespace-Scans, Backup-Katalogisierung, Replikation, Wiederherstellungsverarbeitung und die Konstruktion des Verzeichnisindex nach der Wiederherstellung verlängern. Beispielsweise repliziert NetApp SnapMirror geänderte Metadaten ebenso wie Dateidaten, sodass eine Baseline oder ein Update mit vielen Erstellungs-, Lösch- oder Umbenennungsvorgängen selbst bei geringem Dateivolumen und geringem Platzbedarf aufwändig sein kann. Diese Herausforderungen können sich auch auf NDMP-basierte Backups auswirken.

Informationen zur Verzeichnisindexübertragung mit SnapMirror finden Sie unter "Verzeichnisindizierung in ONTAP".

maxfiles (konfiguriert als Volume-Option -files) ist eine konfigurierbare Obergrenze für die Anzahl öffentlicher Inodes, die in einem einzelnen Volume verfügbar sind. Diese Anzahl umfasst nicht nur Dateien und Verzeichnisse, sondern auch benannte Streams, ACLs und andere öffentliche Objekte, mitunter Objekte, die in einer regulären Verzeichnisauflistung nicht angezeigt werden. Das Volume enthält eine versteckte Inode-Datei, die diese Einträge speichert. ONTAP vergrößert die Inode-Datei, wenn ein neuer öffentlicher Inode benötigt wird und kein freier Eintrag mehr vorhanden ist, bis zur Einstellung -files und zur Gesamtgröße des Volumes. Der konfigurierbare Maximalwert für -files hängt von der Volume-Größe und den ONTAP Grenzwerten ab.