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

    chkdsk auf Volume mit ReFSDie Alter­native zum lange schon bewährten NTFS heißt seit Server 2012 Resi­lient File Sys­tem (ReFS). Wie der Name nahe legt, ist dieses Datei­system wider­stands­fähiger gegen Feh­ler. Seine Stär­ken zeigen sich auf Volumes für vir­tu­elle Maschinen und bei Storage Spaces Direct.

    Microsoft entwickelte den proprietären Nachfolger von NTFS 3.1 unter anderem, um dem stetig wachsenden Daten­aufkommen gerecht zu werden. Die ersten Versionen von ReFS wurden jedoch durch Drittanbieter nur unvollständig unterstützt, außerdem war unter Server 2012 (R2) auch der Einsatz als Dateisystem für Hyper-V aus Performance-Gründen nicht freigegeben (Stichwort: Integrity Streams).

    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!

    Abfrage der ReFS Version und Beispiel zu Chkdsk: gegen ein ReFS Volume nicht erforderlich.

    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".

    Microsofts Dokumentation zufolge wird ReFS auf SAN-Speichern nicht unterstützt.

    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 = 1015 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.

    Integrity Streams sind standardmäßig deaktiviert

    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:

    Vergleich zwischen ReFS und NTFS, hier: gemeinsame Funktionen. Stand: Anfang 2016, Quelle: Microsoft

    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:

    Unterschiede zwischen ReFS und NTFS. Stand: Anfang 2016, Quelle: Microsoft 

    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:

    ReFS im Zusammenspiel mit Cluster Shared Volumes

    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).

    ReFS beschleunigt das Anlegen von fixen VHDX erheblich.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.

    15 Kommentare

    Bild von Jerry B
    Jerry B sagt:
    15. Januar 2019 - 16:46

    Habe ReFS testweise ausprobiert.

    Was in der Theorie gut klingt ('besonders robust bei großen Datenmengen') erwies sich in der Praxis schnell als mittelschwere Katastrophe.

    Ein nach einer Woche erfolgter Stromausfall führte beim nächsten Neustart dazu, dass das ReFS Volume als 'RAW' deklariert wurde. Kaltstart halft nicht, Powershell-Reparaturversuche ebenso wenig. Das Volume blieb 'RAW'.

    Einziger Ausweg war dann Anwerfen einer Datenrettungssoftware, die für 20TB erwartungsgemäß mehrere _Tage_ benötigte.

    Ein mit ReFS formatiertes externes RAID Array ging auch ohne Stromausfall nur aufgrund starker I/O-Belastung nicht reparierbar in den RAW-Modus. Gleiches Spiel wie vorher.

    Von daher: ReFS? Danke, aber »Nein Danke«.

    Dass MS irgendwann native Unterstützung für ein ausgereiftes Dateisystem wie BTRFS oder ZFS bereitsstellt, bleibt wohl leider Wunschdenken.

    Bild von Marcel Küppers
    17. Januar 2019 - 13:14

    Welche Serverversion bzw. ReFS-Version kam denn zum Einsatz?

    Bild von Jerry B
    Jerry B sagt:
    17. Januar 2019 - 13:40

    Pro for Workstation auf aktuellem Stand. Müsste also auch das aktuelle ReFS v3.1 (gewesen) sein. Wie erwähnt existieren die Vols als ReFS nicht mehr.

    Bild von Marcel Küppers
    17. Januar 2019 - 17:08

    Als Einsatz-Beispiel fällt mir da spontan Azure Stack ein. ReFS ist Grundlage hier für S2D, BLOB basiert somit auf ReFS. Ich kann mir nicht vorstellen, dass MSFT dieses Risiko eingehen würde, wenn ReFS nicht ausgereift genug wäre. Backups sind bei allen File-Systemen notwendig. Wenn es das Backup-Volume betrifft, suboptimal.

    Bild von Jerry B
    Jerry B sagt:
    17. Januar 2019 - 18:15

    Wie gesagt, in der Theorie alles wunderbar. Die beiden von mir geschilderten Fälle sind innerhalb von zwei Tagen aufgetreten. Und Google liefert leider einige Beispiele dafür, dass ich mit diesen Problemen keinesfalls alleine dastehe. Z.B. mit dem Suchstring 'ReFS volume goes raw'.

    Mag sein, dass ein vermutlich gespiegelter Server mit redundantem Netzteil an einer kräftigen USV da mit ReFS weniger Probleme macht. Wobei man zum einen in dem Bereich auch ohne Probleme Linux und eben BTRFS oder ZFS nehmen kann. Zum zweiten gibt es auch Testberichte darüber, dass ReFS bei aktivierter Data Integrity bei hoher I/O Belastung nach wenigen Minuten völlig zusammenklappt.

    Für den ambitionierten Windows Heim-Anwender rate ich von ReFS ab. Intern NTFS, extern zum sichern ein Linux NAS.

    Bild von Marcel Küppers
    18. Januar 2019 - 8:05

    "Google liefert leider einige Beispiele dafür, dass ich mit diesen Problemen keinesfalls alleine dastehe. Z.B. mit dem Suchstring 'ReFS volume goes raw'."

    Google liefert auch einige Ergebnisse zu "ZFS issues".

    Auch in Verbindung mit ReFS liefert MSFT Updates und How-to´s:

    https://support.microsoft.com/en-us/help/4016173/fix-heavy-memory-usage-...

    Bild von Jerry B
    Jerry B sagt:
    18. Januar 2019 - 21:15

    Danke für den Tipp mit den Registry Tweaks. Ich werde es auf einem unkritischen Volume noch einmal testen.

    Wobei ich mich trotzdem frage, ob ich – was ReFS angeht – einfach ein ausgesprochener Pechvogel bin oder ob das an Inkompatibilität meiner Hardware liegt. Intern ein Adaptec 8805, an dem 7x 8TB als RAID 6 hängen, extern ein als RAID 3 konfiguriertes Sharkoon 5x 8TB eSATA DAS.

    Bild von Marcel Küppers
    19. Januar 2019 - 10:54

    Ich finde Deinen RAID Controller nicht im Windows Server Catalog:

    https://www.windowsservercatalog.com/

    Das heisst, er ist nicht getestet für mindestens Windows Server 2016 und hat kein certified Logo (oder wurde getestet und hat nicht standgehalten).

    Dann halte ich es für essentiell einen RAID Controller mit BBU bzw. BBWC im Fall eines Stromausfalls zu betreiben. Auch mit Bezug auf ReFS. Hier über ZMCP:

    https://www.adaptec.com/nr/pdfs/AFM700_ds.pdf

    Bild von Jerry B
    Jerry B sagt:
    19. Januar 2019 - 11:08

    Den Adaptec 8805 betreibe ich inklusive der Battery Unit; daran liegt es nicht.

    Außerdem dürfte er im Server Catalog unter Adaptec Series 8 / Series 7 auftauchen; zumindest stimmen BIOS Version und Datum. Wäre auch eher »slooooow admin« seitens Microsoft, wenn die Ur-Urgroßväter dieses Controllers gelistet wären (z.B. der 5805) und er selbst nicht.

    Bild von Marcel Küppers
    19. Januar 2019 - 11:29

    Die Series 8 ist gelistet:

    https://www.windowsservercatalog.com/item.aspx?idItem=4c4c89d3-a934-6d45...

    Findest Du hier Dein Chipset, Firmware und Driver?

    Bild von Jerry B
    Jerry B sagt:
    21. Januar 2019 - 1:58

    Nachtrag:
    Wie versprochen habe ich auf einem 'unkritischen' Volume noch einmal mit ReFS getestet. Beim Versuch, einen Batzen Audio-Dateien auf dieses zu kopieren (die sowohl auf NTFS als auch auf BTRFS auf einem Linux NAS keinerlei Probleme verursachen), kam in mehreren tausend Fällen reproduzierbar eine Fehlermeldung in der Art 'Kein Zugriff auf Datei ...' Egal mit welcher Software, das Kopieren auf das ReFS Volume wurde glatt verweigert. Eine mit wenigen Sekunden Verzögerung durchgeführte Probekopie auf ein NTFS Volume dagegen funktionierte ohne jedes Problem, ebenso die Kopie auf ein externes Linux NAS.

    In den Ereignisprotokollen zu Disks, Partitions, ReFS finde ich dazu auf Anhieb gar nichts.

    In Anbetracht der vielen innerhalb nur einer Woche erlebten Probleme bleibt es daher für mich persönlich bei dem Statement oben vom 17.01.2019, 18:15 h: Kein ReFS für Produktionseinsätze.

    Natürlich kann jeder das für sich selbst entscheiden. Allgemeine Empfehlung wäre allerdings ein gründliches Testen in einer Art Sandbox mit vollständig gesicherten Daten. Das von mir erlebte Fiasko mit ReFS wünsche ich niemandem.

    Bild von Rainer Winkler
    Rainer Winkler sagt:
    22. Januar 2019 - 12:16

    Man weiß gar nicht was man dazu sagen soll. Verwendet ReFS mit nicht zertifizierter Hardware und beschwert sich im Nachhinein. Jerry hat hier seine eigene Unachtsamkeit dokumentiert und sollte sich Computern nur als Endanwender nähern.

    Bild von Jerry B
    Jerry B sagt:
    22. Januar 2019 - 13:59

    @Rainer: Welche Laus ist Dir denn über die Leber gelaufen?

    Wie oben auch dokumentiert ist, ist die verwendete Hardware sehr wohl zertifiziert.

    Beschwerde? Na, von mir aus. Ich habe geschildert, was mir mit ReFS passiert ist und daraus die persönliche Schlussfolgerung gezogen, es bei mir für Produktionszwecke nicht zu verwenden. Das, was passiert ist, war ungeschönt (und hatte mich auch ordentlich verstimmt), artete hier aber nirgends in krasse Beschimpfung von irgend etwas oder jemanden aus.

    Von daher die Bitte an Dich (Rainer), die Regeln der Nettikette zu beachten. Wenn Du positive Erfahrungen mir ReFS gemacht hast, wären die hier als andere Meinung sicherlich willkommen. Eine Schilderung der Software-Umgebung und der verwendeten Hardware würde das für andere nachvollziehbar machen.

    Nebenbei: Ich führe seit 30 Jahren EDV-Beratungen durch. Hauptsächlich für Endanwender und kleine Firmen, zugegeben. Und sicher nicht mit all dem Fachwissen, über das Marcel laut seiner Vita verfügt. I.d.R. hatte ich allerdings ziemlich zufriedene Kunden. Was bitte sollte ein Endanwender machen, der sich für ReFS interessiert und es einmal testen möchte?

    Bild von TD
    TD sagt:
    31. Januar 2019 - 12:19

    Hallo zusammen,

    ich teile hier auch mal kurz meine negativen Erfahrungen mit ReFs.

    Veeam-Backupserver auf Windows Server 2019 1809, neu aufgesetzt auf ESXi 6.7 ohne irgendwelche Extras.

    32Gb RAM und als Datenplatte für VEEAM eine 25TB große vmdk auf einem IBM Storgae ds3512.

    Deduplizierung aktiviert.

    ReFs wird von VEEAM empfohlen, deshalb habe ich mich erst dazu verleiten lassen.

    Gestern nach einem Neustart (wegen VEEAM Update) "Bluescreen" PAGE FAULT in ReFS.sys
    Erscheint aber erst wenn eigentlich schon fertig gebootet ist.
    Das System läuft schon seit einigen Wochen ansonsten Fehlerfrei.

    Platte zum Test in ein Windows 10 eingehängt und siehe da alles gut, die Daten sind vorhanden und auch ok.

    Das Volume dann auf der Platte mit diskpart readonly gemacht und im Windows Server 2019 wieder eingehängt.
    Alles ok und lesbar.

    Deduplication deaktviert reboot und readonly auf dem Volume entfernt.
    Ergebnis= Bluescreen

    Asche auf mein Haupt, ob der Storage oder ESXi 6.7 von MS zertifiziert ist habe ich nicht geprüft.

    Ich werde jedenfalls einfach aus Zeitmangel wieder mit ntfs formatieren und gut ist.

    Zur Info noch refs.sys auf dem
    Server: Produktversion 10.0.17763.1 vom 15.09.2018
    Windows 10: Produktversion 10.0.17134.1 vom 12.04.2018

    Vielleicht hilft es ja jemand.

    Grüße
    TD