Empfehlungen zur Clustergröße für ReFS und NTFS
IO-Verstärkung:
Unter IO-Verstärkung versteht man eine Vielzahl von Umständen, bei denen ein IO-Vorgang einen anderen auslöst, unbeabsichtigte IO-Operationen. Es kann jedoch den Anschein haben, dass nur ein E/A-Vorgang stattgefunden hat, in Wirklichkeit, Das Dateisystem musste mehrere E/A-Vorgänge ausführen, um die anfängliche E/A erfolgreich zu bedienen. Dieses Phänomen kann besonders kostspielig sein, wenn man bedenkt, dass das Dateisystem verschiedene Optimierungen nicht mehr durchführen kann:
- Beim Ausführen eines Schreibvorgangs, Das Dateisystem könnte diesen Schreibvorgang im Speicher durchführen und ihn bei Bedarf in den physischen Speicher leeren.
- Bestimmte schreibt, Jedoch, könnte das Dateisystem dazu zwingen, zusätzliche E/A-Vorgänge auszuführen, beispielsweise das Einlesen von Daten, die bereits auf ein Speichergerät geschrieben sind. Das Lesen von Daten von einem Speichergerät verzögert den Abschluss des ursprünglichen Schreibvorgangs erheblich, da das Dateisystem warten muss, bis die entsprechenden Daten aus dem Speicher abgerufen wurden, bevor es den Schreibvorgang durchführt.
ReFS-Clustergrößen:
ReFS bietet sowohl 4K- als auch 64K-Cluster. 4K ist die Standardclustergröße für ReFS, Und Wir empfehlen die Verwendung von 4K-Clustergrößen für die meisten ReFS-Bereitstellungen weil es dazu beiträgt, die kostspielige IO-Verstärkung zu reduzieren:
- Im Allgemeinen, wenn die Clustergröße die Größe des IO überschreitet, Bestimmte Arbeitsabläufe können unbeabsichtigte E/A-Vorgänge auslösen. Stellen Sie sich das folgende Szenario vor, in dem ein ReFS-Volume mit 64-KB-Clustern formatiert ist
- Durch die Wahl von 4K-Clustern anstelle von 64K-Clustern, Man kann die Anzahl auftretender IOs reduzieren, die kleiner als die Clustergröße sind, Dadurch wird verhindert, dass kostspielige IO-Verstärkungen so häufig auftreten.
Zusätzlich, 4K-Clustergrößen bieten eine größere Kompatibilität mit Hyper-V IO-Granularität, Daher empfehlen wir dringend, 4K-Clustergrößen mit Hyper-V auf Refs zu verwenden. 64K -Cluster sind anwendbar, wenn sie mit groß arbeiten, sequentielles IO, aber sonst, 4K sollte die Standardclustergröße sein.
NTFS-Clustergrößen:
NTFS bietet Clustergrößen von 512 bis 64K, aber im Allgemeinen, Wir empfehlen eine 4K-Clustergröße auf NTFS, da 4K-Cluster dazu beitragen, den verschwendeten Speicherplatz beim Speichern kleiner Dateien zu minimieren. Wir raten außerdem dringend von der Verwendung von Clustergrößen kleiner als 4K ab. Es gibt zwei Fälle, Jedoch, wo 64K-Cluster angemessen sein könnten:
- 4K-Cluster begrenzen das maximale Volumen und die Dateigröße auf 16 TB
- 64K-Clustergrößen können ein höheres Volumen und eine höhere Dateikapazität bieten, Dies ist relevant, wenn Sie eine große Bereitstellung auf Ihrem NTFS-Volume hosten, wie das Hosting von VHDs oder eine SQL -Bereitstellung.
- NTFS hat eine Fragmentierungsgrenze, und größere Clustergrößen können dazu beitragen, die Wahrscheinlichkeit des Erreichens dieser Grenze zu verringern
- Weil NTFS abwärtskompatibel ist, Es müssen interne Strukturen verwendet werden, die nicht für moderne Speicheranforderungen optimiert wurden. Daher, Die Metadaten in NTFS verhindern, dass Dateien mehr als ~1,5 Millionen Extents haben.
- Man kann, Jedoch, Verwenden Sie die Option „format /L“, um die Fragmentierungsgrenze auf ~6 Millionen zu erhöhen.
- 64K-Cluster-Bereitstellungen sind weniger anfällig für diese Fragmentierungsgrenze, Daher sind 64-KB-Cluster eine bessere Option, wenn die NTFS-Fragmentierungsgrenze ein Problem darstellt. (Datendeduplizierung, spärliche Dateien, und SQL -Bereitstellungen können zu einem hohen Grad an Fragmentierung führen.)
- Die NTFS-Komprimierung funktioniert nur mit 4K-Clustern, Daher ist die Verwendung von 64-KByte-Clustern bei Verwendung der NTFS-Komprimierung nicht geeignet. Erwägen Sie stattdessen eine Erhöhung der Fragmentierungsgrenze, wie in den vorherigen Aufzählungspunkten beschrieben.
Während eine 4K-Clustergröße die Standardeinstellung für NTFS ist, Es gibt viele Szenarien, in denen 64-KB-Clustergrößen sinnvoll sind, wie zum Beispiel: Hyper-V, Sql, Deduplizierung, oder wenn die meisten Dateien auf einem Volume groß sind.
