ReFS oder NTFS: Vor- und Nachteile der Dateisysteme in Windows Server 2016

Doch mit dem Erscheinen von Windows Server 2016 und der darin enthaltenen SDS-Lösung Storage Spaces Direct (S2D) gewinnt auch ReFS (aktuell: Version 3.1) an Bedeutung. Fragen, ob der Einsatz von ReFS zum jetzigen Zeitpunkt sinnvoll ist, erreichen mich im TechNet-Forum des Öfteren und eine Antwort lautet oftmals: it depends!

Einige IT-Pro empfehlen weiterhin die Verwendung von NTFS im SAN für Hyper-V Cluster und auch Microsofts Overview enthält aktuell die Anmerkung: "ReFS is not supported on SAN-attached storage".

Doch wann ist der richtige Einstieg und warum tut sich ReFS so schwer? Hier hilft ein Blick auf den Feature-Vergleich zwischen den beiden Dateisystemen.

Vorteile und Features von ReFS

Wie bereits eingangs erwähnt, eignet sich das neue File-System besonders für ein großes Datenvolumen. ReFS-Datenträger dürfen eine Größe von 35 PB (Dezimal: 1 Petabyte = 1000 Terabytes = 10¹⁵ Bytes) erreichen, NTFS-Volumes dagegen "nur" 256 TB bei einer Cluster-Größe von 64KB. Aber ReFS erlaubt nicht nur größere Volumes, sondern zeichnet sich gegenüber NTFS auch durch Robustheit aus. Dazu tragen folgende Fähigkeiten von ReFS beim Umgang mit möglichen Fehlern bei:

Integrity Streams (Optional): Auf Basis von Prüfsummen (Checksums) für Metadaten und auch Benutzerdaten können Dateien beim Speichern vor Fehlern geschützt werden. Get-FileIntegrity zeigt an, ob das Feature aktiviert wurde. Standardmäßig ist es deaktiviert und sollte es auch bleiben, wenn Performance-sensible Workloads vorkommen.

Integration mit Storage Spaces: Kommen Spiegel- oder Paritäts-Volumes zum Einsatz, ist ReFS in der Lage, Fehler online automatisch zu korrigieren. Volumes müssen somit für die Fehler­korrektur nicht offline genommen werden.

Proaktive Fehlerkorrektur: Zusätzlich zu den Schutz­mechanismen vor dem Lesen und Schreiben werden Volumes regelmäßig auf mögliche Fehler gescannt und ggfs. einer Reparatur unterzogen.

Bei der Entscheidung für oder gegen den Einsatz von ReFS helfen wie gesagt verschiedene Vergleichs­tabellen, welche die derzeitigen Features gegenüberstellen. Beginnen möchte ich mit den Funktionalitäten, die sowohl ReFS als auch NTFS beherrschen. Dazu gehören die Unterstützung für Cluster Shared Volumes, Failover-Cluster oder Snapshots. Die Matrix zeigt alle gemeinsamen Features:

Im weiteren Verlauf zeigt die nächste Tabelle Funktionen von ReFS, die NTFS nicht beherrscht, und dann danach die Funktionen, die ReFS im Vergleich zu NTFS fehlen:

Block Cloning oder Real-time-tier Optimierung bei Storage Spaces Direct kann nur ReFS, dafür fehlt ihm zur Zeit noch die Fähigkeit zur Daten-Deduplizierung (Update Nov. 2017: ReFS mit Windows Server 1709 unterstützt Data Dedup), zum Booten oder zur Festlegung von Datenträger­kontingenten. NTFS hat zum jetzigen Zeitpunkt also noch eine klare Daseins­berechtigung, so dass man stets abwägen muss, welchem Dateisystem man den Vorzug gibt.

Storage Spaces Direct und ReFS

Microsoft empfiehlt den Einsatz von ReFS unter S2D, was beispielsweise bei der Volume-Erstellung via GUI auch immer wieder vorgeschlagen wird. Wenn es explizit gewünscht oder etwa Dedup gefordert ist, dann lassen sich Volumes auch mit NTFS einrichten.

ReFS ist jedoch auf den Einsatz unter S2D ausgelegt, darum sollte es dort auch möglichst zum Einsatz kommen. Benötigt man die Fähigkeiten zum Real-time tiering, dann ist es zwingend notwendig. Prüft man mit Get-ClusterSharedVolumeState den Status eines mit ReFS konfigurierten Volumes, dann bietet sich folgendes Bild:

Bei Einrichtung der Cluster Shared Volumes mit ReFS arbeitet der Verbund im FileSystemRedirected Modus und die Daten fließen nicht mehr direkt zur Disk, sondern per SMB zum Koordinator des Volumes. Daher sollten die Netzwerk­verbindungen zwischen den Knoten performant ausgelegt sein, um Engpässe zu vermeiden (Stichwort hier: SMB Direct). Unterhalb des S2D-Beitrages wurde die Diskussion zum umgeleiteten Traffic schon geführt.

Das folgende Beispiel verdeutlicht die einfache Erstellung der Volumes mit einer Clustergröße von 4K (empfohlen für die meisten Workloads), die ich mit ReFS formatiere und gleichzeitig als Cluster Shared Volume konfiguriere:

New-Volume -StoragePoolFriendlyName "S2D*" -FriendlyName Volume01 `
-FileSystem CSVFS_ReFS -Size 2TB

Äquivalent dazu ein weiteres, formatiert mit NTFS (hier: 4K, empfohlen für Hyper-V 64K):

New-Volume -StoragePoolFriendlyName "S2D*" -FriendlyName Volume02 `
-FileSystem CSVFS_NTFS -Size 2TB

Vorteile bei der Ablage von VHD(X) auf einem ReFS-Datenträger

Einen messbaren Performance-Schub erhält das Anlegen von fixen VHDX-Dateien. In Sekundenschnelle lassen sich diese auf einem ReFS Volume platzieren, wo hingegen der gleiche Vorgang auf einem NTFS-Volume je nach Datenträgerperformance minutenlang vor sich hin arbeitet (ohne ODX im SAN).

Gerade große VMs bzw. VHDX werden mit ReFS schnell ausge­rollt und Speicher unmit­telbar allokiert. Während beim An­legen der virtu­ellen Lauf­werke auf einem NTFS-Volume alle Blöcke genullt werden müssen, mani­puliert ReFS hier zuerst die Meta­daten, bevor Blöcke geän­dert werden. Nachge­stellt habe ich diesen Vorgang in meinem S2D-Hyper-V-Lab, bestehend aus einem Mix von ReFS- und NTFS-Volumes.

Doch auch das Zusammen­führen von Checkpoints (AVHDX) mit der Parent-VHD(X) ist auf einem ReFS Datenträger vergleichsweise schnell erledigt. Auf NTFS-Laufwerken wird beim Auflösen des Snapshots zusätzlicher Platz benötigt, weil die AVHD(X) erst in die VHD(X) einkopiert und dann die AVHD(X) gelöscht werden. Der Vorgang dauert je nach Größe der Differenzplatte relativ lange.

Ohne großartige Datenbewegung lassen sich dagegen Checkpoints eines ReFS-Volumes auflösen, es findet lediglich ein Referenzieren statt. Die neuen AVHD(X) Daten werden weiter genutzt und alte Daten der VHD(X) als ungültig erklärt.