Teilen über


Grundlegendes zu Verzeichnisgrößen in Azure NetApp Files

Wenn eine Datei in einem Verzeichnis erstellt wird, wird einer ausgeblendeten Indexdatei im Azure NetApp Files-Volume ein Eintrag zu hinzugefügt. Diese Indexdatei hilft dabei, die vorhandenen Inodes in einem Verzeichnis nachzuverfolgen und Nachschlageanforderungen für Verzeichnisse mit einer hohen Anzahl von Dateien zu beschleunigen. Da dieser Datei Einträge hinzugefügt werden, erhöht sich die Dateigröße je nach Länge des Dateinamens um ca. 512 Bytes pro Eintrag (aber sie verkleinert sich nie). Längere Dateinamen erhöhen die Dateigröße. Für symbolische Verknüpfungen werden dieser Datei auch Einträge hinzugefügt. Dieses Konzept wird als Verzeichnisgröße bezeichnet und stellt ein gemeinsames Element in allen Linux-basierten Dateisystemen dar. Die Verzeichnisgröße ist nicht die maximale Gesamtanzahl von Dateien in einem einzelnen Azure NetApp Files-Volume. Diese wird durch den maxfiles-Wertbestimmt.

Wenn ein neues Verzeichnis erstellt wird, belegt es standardmäßig 4 KiB (4.096 Byte) oder acht 512-Byte-Blöcke. Sie können die Größe eines neu erstellten Verzeichnisses von einem Linux-Client aus mit dem Befehl „stat“ anzeigen.

# mkdir dirsize 
# stat dirsize 
File: ‘dirsize’ 
Size: 4096            Blocks: 8          IO Block: 32768  directory 

Verzeichnisgrößen sind spezifisch für ein einzelnes Verzeichnis und werden nicht zu einer Größe kombiniert. Wenn z. B. 10 Verzeichnisse in einem Volume vorhanden sind, kann jedes einzelne Volume die 320-MiB-Grenze für die Verzeichnisgröße erreichen.

Feststellen, ob sich ein Verzeichnis der Begrenzungsgröße nähert

Bei einem Verzeichnis mit 320 MiB beträgt die Anzahl der Blöcke 655360, wobei jeder Block eine Größe von 512 Byte hat. (D. h., 320x1024x1024/512.) Daraus ergibt sich für ein Verzeichnis mit 320 MiB ein Maximum von etwa 4-5 Millionen Dateien. Die tatsächliche maximale Anzahl von Dateien ist jedoch ggf. geringer. Dies hängt von Faktoren wie etwa der Anzahl von Dateien mit ASCII-fremden Zeichen im Verzeichnis ab.

Sie können den Befehl stat von einem Client aus verwenden, um festzustellen, ob sich ein Verzeichnis der maximal zulässigen Größe für Verzeichnismetadaten (320 MB) nähert. Wenn Sie die maximale Größenbeschränkung für ein einzelnes Verzeichnis für Azure NetApp Files erreichen, tritt der Fehler No space left on device auf.

Bei einem Verzeichnis mit 320 MB beträgt die Anzahl der Blöcke 655.360, wobei jeder Block eine Größe von 512 Byte hat. (Berechnung: 320 × 1.024 × 1.024 : 512.) Daraus ergibt sich für ein Verzeichnis mit 320 MB ein Maximum von etwa vier Millionen Dateien. Die tatsächliche maximale Anzahl von Dateien ist jedoch ggf. geringer. Dies hängt von Faktoren wie etwa der Anzahl von Dateien mit ASCII-fremden Zeichen im Verzeichnis ab. Informationen zum Überwachen des maxdirsize-Werts finden Sie unter Überwachen von maxdirsize.

Überlegungen zur Verzeichnisgröße

Wenn Sie es mit einer Umgebung mit hoher Dateianzahl zu tun haben, berücksichtigen Sie die folgenden Empfehlungen:

  • Azure NetApp Files-Volumes unterstützen eine Verzeichnisgröße von bis zu 320 MiB. Dieser Wert kann nicht erhöht werden.
  • Sobald die Verzeichnisgröße eines Volumes überschritten wurde, wird für Clients ein Fehler wegen unzureichenden Speichers angezeigt, selbst wenn auf dem Volume freier Speicherplatz verfügbar ist.
  • Bei regulären Volumes entspricht die Größe von 320-MiB-Verzeichnissen etwa 4-5 Millionen Dateien in einem einzigen Verzeichnis. Dieser Wert hängt von der Länge der Dateinamen ab.
  • Große Volumes haben eine andere Architektur als normale Volumes.
  • Eine hohe Anzahl von Dateien in einem einzelnen Verzeichnis kann bei der Suche Leistungsprobleme verursachen. Beschränken Sie nach Möglichkeit die Gesamtgröße eines einzelnen Verzeichnisses auf 2 MiB (ca. 27.000 Dateien), wenn häufige Suchvorgänge erforderlich sind.
    • Wenn mehr Dateien in einem einzigen Verzeichnis benötigt werden, passen Sie die Erwartungen an die Suchleistung entsprechend an. Obwohl Azure NetApp Files die Verzeichnisdateiauflistungen indiziert, um die Leistung zu erhöhen, können Suchvorgänge bei einer hohen Anzahl von Dateien einige Zeit in Anspruch nehmen.
  • Vermeiden Sie beim Entwerfen ihres Dateisystems flache Verzeichnislayouts. Informationen zu verschiedenen Ansätzen für Verzeichnislayouts finden Sie unter Informationen zu Verzeichnislayouts.
  • Um Probleme zu beheben, bei denen die Verzeichnisgröße überschritten wurde und keine neue Dateien erstellt werden können, löschen oder verschieben Sie Dateien aus dem betreffenden Verzeichnis.

Informationen zu Verzeichnislayouts

Der maxdirsize-Wert kann Probleme verursachen, wenn Sie flache Verzeichnisstrukturen verwenden, bei denen ein einzelner Ordner Millionen von Dateien auf einer einzigen Ebene enthält. Ordnerstrukturen, in denen Dateien, Ordner und Unterordner verstreut sind, haben nur geringe Auswirkungen auf maxdirsize. Es gibt mehrere Verzeichnisstrukturmethodiken.

Eine flache Verzeichnisstruktur enthält ein einzelnes Verzeichnis mit vielen Dateien unter demselben Verzeichnis.

Diagramm einer flachen Verzeichnisstruktur

Eine breite Verzeichnisstruktur enthält viele Verzeichnisse auf oberster Ebene und Dateien, die über alle Verzeichnisse verteilt sind.

Diagramm einer breiten Verzeichnisstruktur

Eine tiefe Verzeichnisstruktur enthält wenige Verzeichnisse auf oberster Ebene mit vielen Unterverzeichnissen. Obwohl diese Struktur weniger Dateien pro Ordner bietet, kann die Länge der Dateipfade zu einem Problem werden, wenn die Verzeichnisstruktur zu tief ist und die Dateipfade zu lang werden. Nähere Informationen zu Dateipfadlängen finden Sie unter Grundlegendes zu Dateipfadlängen in Azure NetApp Files.

Diagramm einer tiefen Verzeichnisstruktur

Auswirkungen von flachen Verzeichnisstrukturen in Azure NetApp Files

Flache Verzeichnisstrukturen (viele Dateien in einem oder wenigen Verzeichnissen) wirken sich negativ auf ein breites Feld von Dateisystemen, Azure NetApp Files Volumes oder andere Volumes aus. Mögliche Probleme sind:

  • Hohe Arbeitsspeicherauslastung
  • CPU-Auslastung
  • Netzwerkleistung/Latenz (insbesondere bei Massenabfragen von Dateien, GETATTR-Vorgängen, READDIR-Vorgängen)

Aufgrund des Designs großer Azure NetApp Files-Volumes hat maxdirsize einzigartige Auswirkungen. Der maxdirsize-Wert für großer Azure NetApp Files-Volumes hat aufgrund des Designs einzigartige Auswirkungen. Im Gegensatz zu einem regulären Volume verwendet ein großes Volume Remote-Hardlinks in Azure NetApp Files, um den Datenverkehr über verschiedene Speichergeräte umzuleiten und eine bessere Skalierung und Leistung zu bieten. Bei der Verwendung von flachen Verzeichnissen ist das Verhältnis von internen Remote-Hardlinks zu lokalen Dateien höher. Diese Remote-Hardlinks werden auf den maxdirsize-Gesamtwert angerechnet, sodass sich ein großes Volume möglicherweise schneller seinem maxdirsize-Grenzwert nähert als ein normales Volume.

Wenn ein einzelnes Verzeichnis beispielsweise Millionen von Dateien enthält und etwa 85 % Remote-Hardlinks für das Dateisystem generiert, können Sie davon ausgehen, dass maxdirsize fast doppelt so schnell wie bei einem normalen Volume erreicht wird.

Empfehlungen für optimale Ergebnisse mit Verzeichnisgrößen in Azure NetApp Files:

  • Vermeiden Sie flache Verzeichnisstrukturen in Azure NetApp Files. Breite oder tiefe Verzeichnisstrukturen funktionieren am besten, vorausgesetzt, die Pfadlänge der Datei oder des Ordners überschreitet die NAS-Protokollstandards nicht.
  • Wenn sich flache Verzeichnisstrukturen nicht vermeiden lassen, überwachen Sie den maxdirsize-Wert für die Verzeichnisse.

Überwachen von maxdirsize

Verwenden Sie für ein einzelnes Verzeichnis den Befehl stat, um die Verzeichnisgröße zu ermitteln.

# stat /mnt/dir_11/c5 

Obwohl der Befehl stat verwendet werden kann, um die Verzeichnisgröße eines bestimmten Verzeichnisses zu überprüfen, ist es möglicherweise nicht so effizient, ihn einzeln für jedes einzelne Verzeichnis auszuführen. Um eine Liste der größten Verzeichnisgrößen, sortiert von der größten bis zur kleinsten, zu erhalten, wird der folgende Befehl verwendet, wobei Momentaufnahmeverzeichnisse aus der Abfrage ausgeschlossen werden.

# find /mnt -name .snapshot -prune -o -type d -ls -links 2 -prune | sort -rn -k 7 | head | awk '{print $2 " " $11}' | sort -rn 

Hinweis

Der stat-Befehl gibt die Verzeichnisgröße in Byte aus. Der find-Befehl meldet die Größe in KiB.

Beispiel

# stat /mnt/dir_11/c5 

  File: ‘/mnt/dir_11/c5’ 

  Size: 322396160       Blocks: 632168     IO Block: 32768  directory 
 
# find /mnt -name .snapshot -prune -o -type d -ls -links 2 -prune | sort -rn -k 7 | head | awk '{print $2 " " $11}' | sort -rn 
316084 /mnt/dir_11/c5 

3792 /mnt/dir_19 

3792 /mnt/dir_16 

Im vorherigen Beispiel beträgt die Verzeichnisgröße von /mnt/dir_11/c5 316.084 KiB (308,6 MiB) und nähert sich dem Grenzwert von 320 MiB. Das entspricht etwa 4,1 Millionen Dateien.

# ls /mnt/dir_11/c5 | wc -l
4171624

Ziehen Sie in diesem Fall Korrekturmaßnahmen in Betracht, z. B. das Verschieben oder Löschen von Dateien.

Weitere Informationen