ReFS tut nicht, was es soll

[Snoopy69]

Habe mal testweise die Evaluierungsversion von Windows Server 2012 R2 installiert, weil ich mich von den Fähigkeiten von ReFS überzeugen wollte. Das soll ja Dateien verifizieren und ggf. reparieren können.

Dazu hab ich eine größere Datei auf das mit ReFS-formatierte Laufwerk kopiert und zur Kontrolle noch eine Quersumme (SHA1) mitgegeben. Anschliessend hab ich das Laufwerk vom System getrennt und die vorhandene Datei manipuliert (nur ein Byte). Dann hab ich das Laufwerk wieder eingebunden und die Quersumme über Total Commander laufen lassen. Die Quersumme war dann falsch.

Jetzt frage ich mich, ob ReFS eine Weile braucht, um das zu korrigieren oder kann ReFS keine Dateien reparieren.

 

[smuper]

Nein, das was du vorhast kann kein Dateisystem.(Wenn ich deine Vorgehensweise denn richtig verstanden habe)

Hier eine Erläuterung was ReFS kann:

http://blog.krollontrack.de/refs-was-bedeutet-es-und-wie-funktioniert-es/3203

 

[Masamune2]

Jetzt frage ich mich, ob ReFS eine Weile braucht, um das zu korrigieren oder kann ReFS keine Dateien reparieren.

Ja braucht es, zumindest zum Erkennen des Fehlers. Normal läuft der Check einmal im Monat, du kannst die Prüfung aber auch über die Aufgabenplanung manuell starten. Dazu gibt es einen Task "Data integrity scan"
Reparieren geht nicht so ohne weiteres. Möglich das das funktioniert wenn man unten drunter Storage Spaces nutzt, getestet habe ich es aber noch nicht.

 

[smuper]

@ Masamune2

Kannst du mir erklären wie du die Sachlage verstanden hast?

Wie soll man ein Filesystem testen, das die eigenen Dateien prüfsummenbasiert überwacht? Jede eigenen "Manipulation" wird doch als legitime Änderung angesehen?

So habe ich BTRFS und ReFS bisher verstanden.

 

[Snoopy69]

Aber da steht es doch...

ReFS wurde für den Einsatz in Computersystemen mit großen Datenmengen ausgelegt, wodurch Wert auf eine effizientere Skalierbarkeit und Verfügbarkeit der Daten im Vergleich zu NTFS gelegt wurde. Der Schutz der Datenintegrität war eine der wichtigsten neuen Funktionen, die dem System hinzugefügt wurden, sodass wichtige geschäftskritische Daten bei typischen Hardwarefehlern, die zu Datenverlust führen, besser geschützt sind. Wenn ein Systemfehler auftritt, kann ReFS den Fehler identifizieren und rückgängig machen und das ohne das Risiko eines bleibenden Datenverlusts oder einer Beeinträchtigung des Zugriffs auf das entsprechende Laufwerk. Die Alterung der eingesetzten Speichermedien ist ein weiteres Thema, das auf dieser Ebene ebenfalls angegangen wurde, um Datenverlust zu verhindern, wenn zum Beispiel eine Festplatte verschleißt.

Wenn der "Data integrity scan" einmal im Monat läuft, warum steht der dann nicht in der Aufgabenplanung?

edit:
Habs gefunden - war bissl versteckt...

 

[Asghan]

Wie soll das ReFS denn als Fehler erkennen?
Du hast die Datei ja mit Absicht geändert, so wies auf PCs des öfteren vorkommen soll (hab ich gehört ).

 

[Masamune2]

Jede eigenen "Manipulation" wird doch als legitime Änderung angesehen?

Ja korrekt, aber so wie ich ihn verstanden habe hat er das Laufwerk ausgebaut und von einem anderen OS aus ein Bit geändert ohne die Funktionen des Dateisystems dabei zu nutzen. z.B. mit nem Hexeditor unter Linux.
Ok genau geschrieben hat er das nicht, ich hab es jetzt einfach mal so interpretiert. Zumindest würde ReFS das so erkennen da die Prüfsumme nicht mehr stimmt.

 

[Snoopy69]

Das würde ja bedeuten, dass ReFS nur bei ständig laufendem System (wie es Server in der Regel tun) Sinn macht.
Denn angenommen, der Server ist aus und ein Laufwerk erleidet "Alzheimer", dann wäre es ja das Gleiche, wie ich es getan hab (ein Byte geändert)


edit:
Schade, dass man beim "Data integrity scan" nur den Status sehen kann, aber keinen Fortschritt.
So weiss ich garnicht, wie lange das dauert.

 

[Masamune2]

Ja ein check direkt bei jeder Leseoperation ist meines Wissens so nicht vorgesehen.

 

[Sephe]

Das würde ja bedeuten, dass ReFS nur bei ständig laufendem System (wie es Server in der Regel tun) Sinn macht.
Denn angenommen, der Server ist aus und ein Laufwerk erleidet "Alzheimer", dann wäre es ja das Gleiche, wie ich es getan hab (ein Byte geändert)


edit:
Schade, dass man beim "Data integrity scan" nur den Status sehen kann, aber keinen Fortschritt.
So weiss ich garnicht, wie lange das dauert.

Die Frage ist:

Wie hast du die dieses eine Byte geändert?

Direkt per Roh-Zugriff auf die Festplatte, oder am anderen PC angeschlossen und brav in Notebook ein Zeichen geändert?


Wenn deine Festplatte Probleme hat, kippen die Bytes OHNE, dass das Dateisystem etwas bemerkt ist.

Falls du es an einem anderen PC einfach geändert hast (mit Notepad z.B.), war das eine erlaubte und gültige Änderung, da das Dateisystem ja eingehängt war.

Hintergrund: Die zugehörigen Prüfsummen zu Dateien werden ebenfalls in dem Dateisystem gespeichert. Diese liegen NICHT in der Windows-Registry oder sonst wo.

Wenn du das Dateisystem an einem anderen PC verwendet, sind die Prüfsummen auch da.
Änderst du dann etwas, wird diese Änderung auch im Dateisystem und den Prüfsummen vermerkt.

 

[smuper]

Falls du es an einem anderen PC einfach geändert hast (mit Notepad z.B.), war das eine erlaubte und gültige Änderung, da das Dateisystem ja eingehängt war.

Eben, so sehe ich das auch.

 

[Snoopy69]

Inwiefern ist es eine erlaubte Änderung, wenn es an einem anderen System hing?
Ist es nicht so, dass Server 2012 den Hash bei sich auf dem System hat?

Wenn ich nun die Datei auf einem anderen System ändere, stimmt der Hash ja nicht mehr, wenn ich das Laufwerk wieder an Server 2012 anschliesse. Oder wie genau wird denn die Reparatur durchgeführt? Es müssten ja Redundanzdaten auf Server 2012 liegen, oder?

btw:
Ich hab das Laufwerk von Server 2012 komplett entfernt und an einem anderen PC mittels "Acronis Disk Direktor" bearbeitet.
Dort hab ich ein einziges Byte geändert oder den Sektor gespeichert. Das soll eine Alterung (gekipptes Bit) des Laufwerkes simulieren. Geht das so nicht?

Wenn ihr ein gekipptes Bit/Byte simulieren wolltet, wie würdet ihr das machen?

 

[Masamune2]

Ist es nicht so, dass Server 2012 den Hash bei sich auf dem System hat?

Nein der Hash steht IM Dateisystem. Baust du die Platte woanders ein nimmst du die Hashwerte mit.

Ich hab das Laufwerk von Server 2012 komplett entfernt und an einem anderen PC mittels "Acronis Disk Direktor" bearbeitet.

Das sollte funktionieren. Ich gehe mal davon aus das Acronis kein ReFS versteht.

 

[Holt]

Das würde ja bedeuten, dass ReFS nur bei ständig laufendem System (wie es Server in der Regel tun) Sinn macht.

Solche Filesysteme machen sowieso nur auf Servern Sinn, die erwarten auf Server-HW zu laufen die ECC-RAM hat und dies auch entsprechend unterstützt, da die ihre umfangreichen Metadaten im RAM nicht selbst schützen, was auch vom Aufwand her gewaltig wäre und die Performance in den Keller zwingen würde. Wenn Du kein passendes System hast, lass besser die Finger davon.

Denn angenommen, der Server ist aus und ein Laufwerk erleidet "Alzheimer", dann wäre es ja das Gleiche, wie ich es getan hab (ein Byte geändert)

Wie ich Dir schon im anderen Forum geschrieben habe, erleiden Platten kein Alzheimer, die haben eine ECC über jede Sektor und wenn die Daten nicht zur ECC passen und die Fehler auch nicht korrigierbar sind, dann gibt es keine (korrupten) Daten, sondern einen Lesefehler zurück. Einzig bei den selten auftretenden Fehler auf den internen Datenpfaden können Consumer Platte die da keine Absicherung haben, wirklich mal falsche Daten liefern und wenn man besonderen System hat die spezielle Befehle (ATA Streamungbefehle, SAS RAIDs mit 520/528 Byte pro Sektor) verwenden, aber das ist bei Dir ebensowenig der Fall wie bei allen anderen Heimanwendern.

Inwiefern ist es eine erlaubte Änderung, wenn es an einem anderen System hing?
Ist es nicht so, dass Server 2012 den Hash bei sich auf dem System hat?

Was hast Du denn genau gemacht? Die Platten an einen anderen Rechner gehängt der ReFS unterstützt? Wenn ja, dann wurde das Filesystem normal gemountet, die Änderung als legitim angesehen und ein neuer Hash für die geänderten Daten erstellt und geschrieben. Nur wenn Du Low-Level Änderungen macht, z.B. mit einem HexEditor und besser noch unter Linux, dann wäre es wahrscheinlich das der Hash nicht zu den Daten passt.

Wenn ich nun die Datei auf einem anderen System ändere, stimmt der Hash ja nicht mehr, wenn ich das Laufwerk wieder an Server 2012 anschliesse.

So pauschal stimmt das nicht, s.o.! Beschreibe bitte genau wie diese Änderung erfolgt ist.

hab das Laufwerk von Server 2012 komplett entfernt und an einem anderen PC mittels "Acronis Disk Direktor" bearbeitet.

Unterstützt der ReFS? Wenn ja, dann werden auch die Hash Daten auf die Änderung angepasst worden sein, es liegt damit dann kein Fehler vor. Wenn die das Programm sagen konnte so die Datei auf der Platte liegt, unterstützt es auch ReFS und wenn es Dir das nicht sagen konnte, dann hast Du vielleicht ein Byte einer ganz andere Datei geändert oder eines welches zu keiner Datei gehört.

Dort hab ich ein einziges Byte geändert oder den Sektor gespeichert. Das soll eine Alterung (gekipptes Bit) des Laufwerkes simulieren.

Das tut es aber nicht, denn wie gesagt liefern HDDs eben nicht einfach andere Bytes zurück, auch nicht im Alter. Du leifern stattdessen eben Lesefehler und bekommen dann schwebende Sektoren. Die Simulation ist unrealistisch, wie erwartest Du da realistische Ergebnisse zu bekommen? Du simulierst allenfalls ein auf den Datenpfade gekipptes Bit, aber dagegen sind Serverplatten auch geschützt.

Wenn ihr ein gekipptes Bit/Byte simulieren wolltet, wie würdet ihr das machen?

Du musst zumindest sichergehen, dass die Plattform auf der Du das Bit manipulierst auch ganz sicher kein ReFS unterstützt. Dann musst Du aber vorher sicher sein zu wissen wo die Datei überhaupt auf der Platte liegt, also auf welchen LBAs.