ReFS vs. NTFS

[klaus.m 0]

Werte Server-Spezialisten,

 

das neue Dateisystem ReFS soll ja stabiler und schneller als NTFS sein.

 

Ich plane einen 2012-Fileserver (virtualisiert mit Hyper-V), die Daten liegen in einer VHDX fester Größe auf einem RAID5 (Adaptec) - ist hierfür ReFS tatsächlich die bessere Wahl?

 

Danke für Eure Kommentare,

 

Klaus

[Weingeist 159]

Also bezüglich Fehlerroutinen ist das Teil schon Klasse. Nicht so einfach das System in die Knie zu zwingen. Habe das auf verschiedene Arten ziemlich gut durchtestet (gibt nen Thread hier von mir). Vor allem in Verbindung mit den Software-RAID Features muss wirklich jeder Mirror-Partner Müll abliefern, damit eine Datei Offline geht (nicht das ganze Volume). Sei ein solcher Partner nun ein Volume von zwei verschiedenen externen Speicherboxen welchen zbsp. ein Hardware-RAID zugrunde liegt oder gleich die physischen Discs (interessant mit SSD's --> Trim).

 

Da Writes nicht auf bereits beschriebene Sektoren kommen und diese ersetzen sondern in neue Bereiche geschrieben werden und erst aktiv gesetzt werden wenn der erfolgreiche Write-Commit kommt, macht das File-System extrem robust.

 

Überprüfung und Reperatur von Sektoren geschieht unter ReFs mittels Task Online ohne die Discs oder das Volume Offline zu nehmen. Regelmässig oder per manuellem Anstoss. Bei Benutzung der StorageSpaces (NTFS wie ReFs) scheint das System sehr gut zu wissen, welcher Mirror korrekte Daten liefert und korrigiert diese auf dem oder den Partner. Die fehlerhaften Discs oder DiscSets von einem externen Speicher nimmt Windows nicht Offline sondern schreibt die Daten einfach in andere Sektorenbereiche. Fällt ein solches Discset aus, schreibt es die Daten vom lauffähigen Mirror in ein Hotspare.

 

Gibt aktuell aber auch ein paar lästige Dinge:

- Keine NFS-Freigaben

- Keine Deduplizierung

- Keine Hardlinks

- Keine Quotas

- Keine Cluster-Volumes

 

Auf den ersten Blick mag das ziemlich bekloppt sein, ein neues Filesystem welches ned mal die guten Features des alten hat. Auf den zweiten aber nicht unbedingt verkehrt. Schätze mal MS will das neue Filesystem als reines Filesystem betreiben und die Features via denn StorageSpaces implementieren. Sowohl in Form von eigenen als auch fremden Modulen. Das Filesystems wäre dann nur noch für die reine Ablage von Datenblöcken und deren Korrektheit zuständig. Was ja eigentlich auch dessen Aufgabe ist. Also kein aufbohren mit Features - das übernimmt der zusätzliche Layer (Storage-Spaces) - sondern reine Bereitstellung.

 

Die Features wie Nachschlagwerke welche das Zusammenfassen von Files/Blocks erlauben (Hardlinks, Dedupe) liegen dann ebenfalls als Daten im Filesystem. Diese haben dann automatisch den gleichen Schutz wie die eigentlichen Daten, da sie ja auch als solche abgelegt werden. Das ganze System wird so theoretisch sehr viel robuster, ziemlich sicher auch performanter (Auslagerung der Nachschlagewerke auf andere Disc-Sets usw.) und bietet massig Optimierungsmöglichkeiten für Caching, Dedupe usw. Wird aber auch komplexer. Software-Fehler in einem Nachschlagewerk führen unter Umständen unweigerlich zu massivem Datenverlust. Restore bzw. Rep von zerschossenen StorageSpaces wird wohl nahezu unmöglich werden. Ist aber bei grösseren SAN-Boxen auch nicht besser. Auch da muss die Software ordentlich sein.

 

Soweit meine Einschätzung, wir werden sehen wo das hinführt, ich sehe die Entwicklung diesbezüglich jedenfals positiv. SAN Features unabhängig von Hardware-Hersteller. Gesplittet auf mehrere Partner (zbsp. wie bei DAG bei Exchange) ohne wirkliche Abhängigkeit zueinander (wie bei MS-Cluster) mit beliebigen Skalierungsmöglichkeiten je nach verwendeter, zugrundeliegender Hardware. Die Funktionalität sowie Art der Ablage der Daten ist immer die gleiche.

 

 

Um zu Deiner eigentlich Frage zu kommen: NTFS ist bereits ziemlich robust, bietet für sich mehr Features als ReFs. ReFs ist dagegen extremst robust (Art der Speicherung, freie Bereiche). Steht nur ein Hardware-RAIDset ohne darüberliegenden Software-RAID durch Windows zu Verfügung, werden die Files bei ReFs Online aus dem Filesystem gelöscht ohne dass das Volume wie bei NTFS für Checkdisk offline muss. Bei Verwendung des Software-RAID-Features der StorageSpaces werden die Daten eines sauberen Disc-Sets genommen und die korrupten korrigiert.

Kannst du also auf all die Features die aktuelle NTFS bietet verzichten, dann nimm gleich ReFs. Brauchst Du eines davon, nimm NTFS oder erstelle eine VHD auf einem ReFs welche selber als NTFS formatiert ist.

[Necron 71]

- Keine Cluster-Volumes

Hi,

 

zum Thema Cluster Shared Volumes und ReFS, habe ich seinerzeit mal einen Artikel verfasst: http://www.danielstechblog.de/refs-und-hyper-v/

[Roi Danton 10]

Hi,

 

Offensichtlich kann man auch keine DFS Replikation auf einem ReFs einrichten.

Dafür unterstützt es 32,768 Zeichen lange Datei und Pfadnamen.

Der Traum vieler Nutzer und wahrscheinlich der Horror für jedes Backup :D

 

Hat jemand Erfahrungen im Umgang mit ReFS Backups?

 

Gruß,

 

Roi

[NilsK 2.968]

Moin,

 

Dafür unterstützt es 32,768 Zeichen lange Datei und Pfadnamen.

 

tut NTFS auch. Die Beschränkung liegt im Explorer und den Applikationen.

 

Hat jemand Erfahrungen im Umgang mit ReFS Backups?

 

Auch hier wird die Beschränkung an denselben Stellen liegen.

 

Gruß, Nils

[Roi Danton 10]

Das ist nicht ganz richtig Nils.

NTFS unterstützt nur 32768 Zeichen wenn diese nicht im Unicode vorliegen.

Das ist keine GUI Beschränkung! Da aber der Explorer ausschließlich Unicode verwendet, sind es nur 255 Zeichen.

ReFS kann jetzt 32768 Zeichen in UniCode. Somit kann es auch der Explorer und andere Anzeigen.

[prival 10]

Auch wenn der Artikel schon etwas älter ist, möchte ich den doch gern ergänzen, weil hier fehlerhafte Infos vorliegen.

 

Die Einschränkung von 260 Zeichen liegt in der verwendeten API, die so ziemlich jedes Programm, inklusive dem Explorer, nutzt. NTFS kann Pfade mit circa 32.767 UTF-16 Zeichen verwalten. Quelle: https://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx#maxpath. Und UTF steht für Unicode Transformation Format. ;)

 

ReFS ist auch den Einschränkungen der API unterlegen. Demzufolge kann ein File Server mit ReFS auch keine längere Pfadnamen verwalten. Das ist nicht nur graue Theorie, das habe ich bereits intensiv getestet, weil wir hier öfters die Problematik mit zu langen Pfadnamen haben.

 

Aktuell ist ReFS ganz nett, aber die Einschränkungen machen es derzeit nicht wirklich attraktiv. Klar, wer Stabilität sucht, wird sie bekommen. Schneller als NTFS ist es nicht, im Gegenteil. Die Unterstützung durch andere Produkte (Dritthersteller) ist oft fraglich.

Aber ReFS wird weiter entwickelt, wie es auch bei NTFS war. Microsoft ist dafür bekannt, dass es früh Technologien auf den Markt wirft und den Kunden als Tester verwendet, um das Produkt weiter zu verbessern. Daher sehe ich persönlich noch davon ab. Bin aber sehr gespannt auf die kommenden Versionen. Bis dahin werden hoffentlich viele Hersteller ReFS in ihre Produkte (Backup, Archivierung, etc.) implementiert haben und gut funktionieren. Bisher ist mir das aber noch zu experimentell, um es produktiv zu nutzen.

 

Gruß,
Prival

bearbeitet 27. April 2015 von prival

[zahni 558]

Hi,

das schrieb Nils weiter oben in Kurzform auch schon.

Das Problem sind entsprechende Shell32- und andere Filesystem-APIs, die man nicht einfach auf 32k Pfadlänge umstellen kann. Dann würde nämlich darauf zugreifende Anwendungen nicht mehr funktionieren. Die müssen nämlich intern dann auch damit umgehen können. Darum ändert man solche APIs nicht, sondern baut maximal eine Erweiterung  ein. 

[Weingeist 159]

Passt hier grad: ReFs hat(te?) einen unsäglichen Bug welcher wohl durch die neue Speichermethode verursacht wird. Es kann sein, dass ReFs ned bemerkt, wenn die Festplatte voll wird. Das Volume wird dann  unbrauchbar.

 

Wenn jemand grad infos zur Hand hätte ob das nun gefixt ist, wärs cool. Ist ne gute Zeit her seit ich den Kram getestet habe.

[prival 10]

das schrieb Nils weiter oben in Kurzform auch schon.

 

Ich bezog mich auch auf den letzten Post von Roi, welcher dem Post von Nils widersprach. 

 

@Weingeist: Sorry, dazu kann ich nichts sagen.

 

Gruß,

Prival

[gysinma1 13]

Dann kommt noch was dazu, was ich im Felde auch schon getroffen habe. Kunden, die ReFS für System Center Configuration Manager Komponenten Server (SCCM) einsetzen wollten z.bsp. Distritbution Points. ReFS formatierte Volumes können dazu generell nicht verwendet werden sondern nur NTFS. Das ist v.a. ärgerlich, wenn in Aussenstandorten ReFS formatierte Volumes für einen Distribution Point liegen. Im SystemCenter Umfeld (ausser virtualisierungen) sehe ich keinen Vorteil von ReFS.

bearbeitet 4. Mai 2015 von gysinma1

[Dukel 457]

Zwecks Performance solltest du das einfach mal testen.

 

Ich habe mir zu hause etwas neue Hardware hingestellt. 2x SSD (128GB) + 2x HDD (2TB) als Datenlaufwerk. Mit Storage Spaces (Mirror), Tiering und Write-Back-Cache.

Jeweils einmal mit NTFS und ReFS formatiert. Danach mit SQLIO Benchmarks gemacht. Diese sind nicht zu verallgemeinern, das muss man in jeder Umgebung selbst testen.

 

Jeweils IO/s und MB/s:

Bei 8k Random lesend ist NTFS über 300x schneller

IO/s: 245 ReFs, 80.000 NTFS; MB/s: 2 ReFS, 620 NTFS

schreibend ist NTFS über 200x schneller

IO/s: 200 ReFS, 48.000 NTFS; MB/s: 2 ReFS, 380 NTFS

 

Bei 512k seq lesens ist NTFS knapp 7x schneller

IO/s: 285 ReFs, 2.000 NTFS; MB/s: 140 ReFS, 990 NTFS

schreibend ist NTFS 26x schneller.

IO/s: 40 ReFS, 990 NTFS; MB/s: 20 ReFS, 500 NTFS

[Doso 77]

Mit Server 2016 könnte es interessant werden. Auf der Ignite hat Microsoft gezeigt, das sich VHDX auf dem REFS ohne Verzögerung erstellen lassen, was auf NTFS ja durchaus mal eine Weile dauern kann. Denke da kommt noch mehr.

bearbeitet 29. Mai 2015 von Doso

[Necron 71]

Mit Server 2016 könnte es interessant werden. Auf der Ignite hat Microsoft gezeigt, das sich VHDX auf dem REFS ohne Verzögerung erstellen lassen, was auf NTFS ja durchaus mal eine Weile dauern kann. Denke da kommt noch mehr.

Aber auch nur, wenn du Storage Spaces verwendest. ;)

[v-rtc 91]

Hallo,

 

interessanter Post. Gibt es hier Neuigkeiten? Auch in Bezug auf Fileserver und DFS (ist das nun supported)?

 

Viele Grüße

bearbeitet 20. Oktober 2015 von RolfW