Ist ReFS ein sicheres Dateisystem?

Vielen Dank für die regen Kommentare

Zitat von darkside40

Hier mal ein schönes Beispiel wo in einem Bild ca. 1000 bits verändert werden und es keinen (sichtbaren) Unterschied macht:

Tja, es kommt halt immer drauf was es im Bild erwischt. Von meinen 6 Dateien, die korrupt waren, waren zwei Bilder dabei.
Einem Bild habe ich nichts angesehen und das andere war im oberen Teil ca. 10% sichtbar ok und dann nur noch grau, also unbrauchbar.

Für einen Datenserver habe ich mir auch schon TrueNAS aufgesetzt und ein wenig ausprobiert. TrueNAS mit ZFS finde ich für diese Anwendung wirklich auch toll mit den ganzen Features. Allerdings kommt ein weiteres Gerät hinzu, das auch permanent laufen muss und Strom braucht. Außerdem kommt hinzu, das ganze auch sauber zu verwalten und im Notfall auch das Richtige zu tun. Ohne Terminalbefehle, sprich Kenntnisse und KnowHow, geht das sonst auch nicht.

Auf meinem bisherigen Windows-Server läuft auch noch der DVBViewer und der DVBMediaServer als Aufnahmerecorder. Und das sehr zuverlässig und gut. Das fesselt mich eben auch an die Windows-Welt.

Somit wäre ReFS doch wirklich eine gute Lösung. Ist doch super: Datenintegrität on the fly.
Bei einem StorageSpace, würde ich alles nur mit Mirrors machen, gibts dann eine automatische Reparatur der korrupten Dateien.
Warum soll ich mich darum kümmern, wenn es das System in Echtzeit kann.

Mit SnapRaid habe ich da doch immer eine Lücke, bzw. muss ich das Scrubben regelmäßig durchführen. Macht man das bei >10TB?

Die Frage ist eben, ob das ReFS wirklich in der Praxis so gut funktioniert, wie das Microsoft verspricht.
Erst wenn ich weiß, ob und wie zuverlässig das ganze funktioniert kann ich entscheiden, ob ich es auch einsetzen möchte.
Insbesondere bei Windows 10 Pro for Workstation habe ich von diesen kritischen Berichten bzw. von diesen schlechten Erfahrungen gelesen.

Ich versuche eben den Weg der bitteren Erfahrung etwas abzukürzen und frage deshalb mal hier nach:)

Es gibt neue Erkenntnisse zu ReFS. Ich war heute morgen aktiv und habe ein paar Tests gemacht.

Ich habe zwei zusätzliche Festplatten in meinen PC mit Windows10Pro for Workstation eingebaut.
X:\ mit NTFS
Y:\ mit ReFS
Auf jedem Laufwerk habe ich eine Testdatei.txt angelegt und mit dem Tool WinMD5Free die Prüfsummen ermittelt.

Dann habe ich mit einem DiskEditor die Dateiinhalte der beiden Testdateien an einer einzigen Stelle um ein Byte geändert. Das simuliert quasi einen Bitrot.
Das Dateisystem hat von dieser Änderung nichts mitbekommen. Das sehe ich daran, dass sich das Änderungsdatum der Datei nicht geändert hat.

Bemerkung: Ich hatte am Anfang einen HexEditor eingesetzt, der auf Dateiebene arbeitete. Dadurch hat dann das Dateisystem die Änderung mitbekommen. Deshalb habe ich den DiskEditor verwendet, der direkt auf die Sektoren der Festplatten schreibt und das Dateisystem umgeht.

Die MD5 Prüfsummen der Dateien haben sich, wie zu erwarten war, auch geändert. Beide Dateien konnte ich im Editor wieder öffnen.
Beide Dateisysteme NTFS und ReFS haben den Bitrot nicht erkannt.

Erstmal überlegt: Warum kann ReFS den Bitrot nicht erkannt? Achso, da war die Sache mit dem IntegrityStream, der standardmäßig deaktiviert ist.

Ich habe die Änderungen auf der ReFS rückgängig gemacht und den IntegrityStream aktiviert:
-->set-fileintegrity y:\Testdatei.txt -enable $True

Jetzt habe die Änderung mit dem DiskEditor wieder gemacht.
Die Datei war im Datei-Explorer nach wie vor zu sehen. Das Änderungsdatum hat sich nicht geändert.
Aber: Beim Versuch die Datei zu Öffnen kommt jetzt eine Fehlermeldung: "Die Datei Testdatei.txt kann nicht geöffnet werden"
Die Datei wird also von Windows jetzt als fehlerhaft erkannt und ein Zugriff nicht mehr zugelassen.
Auch ein Kopieren der Datei geht nicht mehr. Hier kommt ein Hinweis, dass ein Fehler in der Prüfsumme und Dateiintegrität vorliegt.

So wie das aussieht funktioniert die Bitrot-Erkennung mit ReFS.

Da ReFS nur auf einer einfachen Festplatte ist, kann natürlich keine automatische Fehlerkorrektur erfolgen.
Das werde ich im nächsten Schritt ausprobieren.
Aber: Das Dateisystem ReFS merkt auf jeden Fall die korrupte Datei und zeigt diese an.

Zitat von te36

Aber wenn die Datei jetzt eine Mediendatei waere, und du da nachgucken wolltest ob die noch "geniessbar" ist. Wie machst Du das dann bei ReFS ?

bin gerade dabei und habe folgendes herausgefunden:

Wenn man den IntegrityStream (also die Prüfsummenerkennung) für die korrupte Datei wieder deaktiviert, dann kann man wie gewohnt auf die Datei zugreifen. Dann könnte man z.B. die Mediendatei prüfen und nachschauen ob diese noch abspielbar ist.

In meinem Fall habe ich in der Testdatei.txt nur eine Jahreszahl geändert. Deaktiviere ich die Prüfsummenerkennung, dann kann ich die Datei wieder mit dem Editor öffnen und beschreiben. Ich habe ja keine defekte Festplatte, sondern den Fehler nur simuliert (durch die Änderung des Bytes mit dem DiskEditor).

Und noch weiter:
Wenn ich jetzt die Prüfsummenerkennung wieder aktiviere, dann wird die Prüfsumme neu berechnet und für ReFS ist die Datei wieder ok.

In der Powershell gibt es auch noch den Befehl repair-fileintegrity.
Den habe ich auch versucht auf die Datei anzuwenden, aber Windows spuckt die Fehlermeldung aus, dass keine Redundanz vorhanden ist.
Dies ist ja auch vollkommen richtig. Man sollte ReFS ja auch immer mit Speicherplätzen (StorageSpaces) verwenden. Wenn ich mal den Mirror unter den Speicherplätzen eingerichtet habe, werde ich das auch ausprobieren.

Übrigens: Die ganzen fehlerhaften Zugriffe werden im Ereignisprotokoll aufgelistet. Unter Quelle steht ReFS. Man kann also auch dort reinschauen und sieht welche Dateien von einem Prüfsummenfehler betroffen sind.

Zitat von SkyBird1980

Edit: Natürlich gibts auch eine Wiederherstellungsfunktion bei ReFS, aber okay. ;p

soweit bin ich noch nicht ... momentan wollte ich erst einmal ausprobieren, ob und wie ich an eine korrupte Datei herankomme.
Ich habe nämlich gelesen, dass die korrupten Datei gelöscht werden.
Das scheint aber nicht der Fall zu sein. Nur der Zugriff auf die Datei wird unterbunden. Und man kann wohl auf verschiedene Arten auch manuell eingreifen. Die automatische Reparatur funktioniert nur bei StorageSpaces mit Redundanzen.

Nun habe ich einen Mirror-Pool mit zwei Festplatten erstellt.
Die Festplatten sind in einem "Speicherplatz" als Laufwerk Z:\ im System zu sehen. Dateisystem ReFS.

Beim der Erstellung eines Bitrots habe ich allerdings ein Problem.
In der Datenträgerverwaltung sind die einzelnen Festplatten als Datenträger nicht mehr zu sehen.
Anstatt dessen ist ein neuer Datenträger zu sehen, der den Verbund der Festplatten darstellt.
Soweit ist denke ich alles normal.

Mit dem Diskeditor kann zwar ich zwar die einzelnen Festplatten sehen. Ich kann auch den Sektor finden der meine Testdatei enthält, den ich verändern möchte. Aber beim Abspeichern des Sektors bekomme ich einen "Systemfehler. Code:5 Zugriff verweigert" vom Diskeditor.

Irgendwie klappt das nicht. Ich vermute, dass Windows den Speicherpool irgendwie schützt.
Hat mir jemand einen Tipp, wie ich den Bitrot erzeugen kann?

Mit einem Linux-System booten und die Festplatte bearbeiten? Gibt es da einen Diskeditor oder Tools die zu empfehlen sind.

Neues von der Bitrot-Creators-Factory

Also ich kann nun Bitrots auf den ReFS formatierten HDDs erzeugen.

Leider hat der DiskEditor unter Windows nicht funktioniert (hängt wohl mit irgendwelchen Zugriffsrechten zusammen).
Deshalb habe mir ein Linux Mint auf den USB-Stick installiert.
Hier installiere ich den DiskEditor Active@DiskEditor. Übrigens ein sehr schönes Tool.

Nun suche ich nach dem Inhalt meiner Testdatei.txt.
Der Sektor wird entsprechend im DiskEditor angezeigt. Hebt man noch den Schreibschutz auf, dann kann man ein Byte ändern und auf der Festplatte die Änderung speichern.

In dem Mirror-Verbund der beiden Festplatten, gibt es nun also unterschiedliche Zustände der Dateien. Auf einer Festplatte ist jetzt ein Prüfsummenfehler vorhanden.
Starte ich nun Windows läuft alles völlig unspektakulär ab.

Ich überprüfe, dann zunächst mit der Windows-Version des DiskEditor, ob der Bitrot auf der Festplatte vorhanden ist. Check ... er ist drauf.

Dann rufe ich die Testdatei.txt mit dem Editor auf. Alles lesbar, keine Fehlermeldung. Der ursprüngliche Zustand wird angezeigt.
Aber im Hintergrund wurde die Datei repariert!
Wenn ich nun mit dem DiskEditor mir nocheinmal die Sektoren anschaue, dann ist wieder zweimal der gleiche Inhalt zu sehen.
Der Fehler wurde also erkannt und vollautomatisch korrigiert.

Das selbe habe ich auch überprüft, in dem ich nur die Eigenschaften der Testdatei abgefragt habe. Auch danach ist der Bitrot korrigiert.

Mein Fazit: ReFS repariert sich selbst und der Mechnismus funktioniert. Windows10Pro for Workstation reicht hier völlig. Allerdings darf man nicht vergessen die IntegrityStreams zu aktivieren!