Windows 10 - Einsatz von ReFS

Paddii

Lt. Commander
Registriert
Okt. 2008
Beiträge
1.345
Hallo zusammen,

seit der neusten Windows 10 Version kann man ja bei internen und externen Festplatten ReFS als Dateisystem nutzen. Ich hatte jetzt überlegt voll drauf umzusteigen, weil ReFS ja durch den integrierten CRC abgleich deutlich stabiler sein soll als NTFS, grade was die Langzeitarchivierung angeht.

Ich hätte jetzt nur eine Frage zu genau diesem CRC Abgleich. Ich konnte hierzu Online leider nicht viel finden.

Wenn ich das richtig verstanden habe, ist bei ReFS Standardmäßig nur der CRC Abgleich der Metadaten aktiviert, aber nicht der Abgleich der ganzen Datei? Grade das wäre ja eigentlich die beste neue Eigenschaft von ReFS.

Laut Microsoft kann man diese Funktion auch für die ganze Platte über Powershell mit "PS X:\> Get-Item -Path 'X\*' | Set-FileIntegrity -Enable $True" aktivieren.

Meine Frage wäre jetzt im Grunde nur, ob ich das so richtig verstanden habe?

Wäre eine solche Konfiguration sinnvoll? Oder sollte man die volle FileIntegrity eher ausgeschaltet lassen?

Einsatzzweck wären bei mir 2 wenig benutze Datenplatten (2x6T).

Liebe Grüße
 
Hi,

lies dir doch die Technet Artikel dazu durch:

https://docs.microsoft.com/de-de/windows-server/storage/refs/integrity-streams

Es kann zu Leistungseinbussen kommen, wie genau sich das jetzt auswirkt weiss ich nicht, da ich noch keine Integrity Streams getestet habe. Ich hab hier 3 LUNs mit je 16 TB die ReFS 3.1 formatiert sind als Backup Target und die sparen mir ordentlich Platz ein. Also als Datengrab echt zu empfehlen.
 
ReFS macht dort Sinn, wo man es mit Storage Spaces zusammen einsetzen kann. Dann wird bei einem erkannten Fehler die Datei vom unbeschädigten Datenträger genommen und die defekte ersetzt.

Bei EINER Festplatte, kannst du dir das natürlich sparen.

•Wenn ReFS ist auf einem nicht stabilen, einfachen Speicherplatz oder einem leeren Laufwerk bereitgestellt wird, gibt ReFS einen Fehler an den Benutzer zurück, ohne die beschädigten Daten zurückzugeben.

Wenn du deine beiden Platten in zu einem Storage Space mit Spiegelung zusammenführst, hat es dann deine gewünschte Funktion.
 
Zuletzt bearbeitet:
Die CRC Checksums werden dir am Ende nur sagen können: Datei ist okay oder Datei ist defekt. Nicht mehr, nicht weniger.

Damit lassen sich keine Daten wiederherstellen. Sonst würde man auf BluRays wohl auch nur noch einen wenige Byte großen CRC Hash ablegen und dann daraus den mehrere Gigabyte großen Film berechnen ;) Dann bräuchte man auch keine BluRays mehr, sondern würde auf 5 1/4" Disketten setzen :D
 
Verstehe ich nicht, ich habe mehrfach gelesen, dass ReFS Dateikorruption erkennt und beheben kann - kann sein das es zum Beispiel maximal 1% ist??
 
Wird im verlinkten Artikel doch ausführlich erklärt. Natürlich kann ReFS das, allerdings nur wenn es in einem Spiegelsatz verwendet wird und nicht bei einer einzelnen Festplatte.

Bei einer einzelnen Festplatte geht man sogar aus verschiedenen Gründen ein zusätzliches Risiko ein, weil es kein chkdsk gibt und auch jegliche Reperatur- oder Wiederherstellungstools damit nicht funktionieren.

Vom Prinzip hat ReFS nur ein paar wenige Bereiche wo es gut ist und wurde deshalb nicht als Ersatz sondern als ein zusätzliches FS von Microsoft zur Verfügung gestellt. Die Bereiche sind Storage Spaces, Datenträger mit sehr vielen Dateien (Milliarden) und neuerdings auch Datenträger für Hyper-V Maschinen.
 
Vielen dank für die Info.

Ich bin jetzt auch etwas verunsichert.

Das eine Reparatur ohne Spiegel nicht möglich ist, was mir soweit schon klar. Mein Ziel war es halt einfach zu erkennen ob es defekte Dateien gibt, damit sich der Fehler nicht irgendwann auch durch die Backups frisst. Wenn es einen Fehler gibt kann man diese Datei ja (Manuell) über ein Backup wiederherstellen.
Wobei hier die Frage stellt, wann genau ReFS die Daten überprüft? Nur wenn man sie öffnet? In dem Fall würde sich der Fehler ja auch durch die Backups fressen wenn man die Datei Monate/Jahrelang nicht öffnet?

Ursprünglich hatte ich eigentlich geplant eine CRC32 oder MD5 Hash der ganzen Festplatte(n) zu erstellen und diesen ab und an zu überprüfen. Hier hatte ich ReFS eigentlich als praktische Alternative angesehen, weil es eigentlich genau das machen sollte, nur halt selbstständig und voll in Windows integriert.

Ist es für meinen Fall gar nicht empfehlenswert ReFS zu benutzen? Bzw. sollte man einfach die Integrity Streams deaktiviert lassen?


Btw.: chkdsk soll ja bei ReFS nicht mehr benötigt werden, weil es die Metadaten erst löscht wenn es die neuen geschrieben hat. So sollte es auch bei Stromausfällen zu keinem direktem Datenverlust kommen.
 
Zuletzt bearbeitet:
Ich weiß nicht, wie ReFS die Dateien ablegt. Aber wenn es nur eine Checksumme für jede ganze Datei gibt, wäre das ziemlich eklig bei VM Images oder 4K Videos, wenn der jedes mal beim Öffnen die Checksumme überprüft. Wenn er allerdings (sagen wir mal) pro Megabyte einer Datei eine Checksumme anlegt, könnte das deutlich angenehmer von der Hand gehen.
 
Paddii schrieb:
Ursprünglich hatte ich eigentlich geplant eine CRC32 oder MD5 Hash der ganzen Festplatte(n) zu erstellen und diesen ab und an zu überprüfen. Hier hatte ich ReFS eigentlich als praktische Alternative angesehen, weil es eigentlich genau das machen sollte, nur halt selbstständig und voll in Windows integriert.

Dafür ist ReFS mit Spiegelsatz bestens geeignet.

Der Vorteil ist, dass du nicht unbedingt Integrität für den gesamten Datenträger benötigst. Für Filmchen oder Audiodateien interessiert es meistens keine Bohne.

Paddii schrieb:
Btw.: chkdsk soll ja bei ReFS nicht mehr benötigt werden

Chkdsk kann aber mehr als nur nach Fehlern im FS zu suchen. Es kann auch nach Fehlern auf dem Datenträger suchen und defekte Sektoren ummappen. Bei ReFS verlässt man sich auf die Funktion vom FS. Ich habe selbst schon mal erlebt, dass sich ein Datenträger wegen defekt am ReFS nicht mehr ansprechen lies. Ohne eine Datensicherung (die man haben sollte) wären die Daten jetzt futsch während man mit NTFS entweder mit Chkdsk oder diversen Tools bestimmt noch fast alles hätte sichern können.

Wie gesagt. ReFS ist ein Nischen-FS und bietet ein paar Vorteile. Als Ersatz für NTFS taugt es aber für die breite Masse (noch) nicht.
 
xexex schrieb:
ReFS macht dort Sinn, wo man es mit Storage Spaces zusammen einsetzen kann. Dann wird bei einem erkannten Fehler die Datei vom unbeschädigten Datenträger genommen und die defekte ersetzt.

Bei EINER Festplatte, kannst du dir das natürlich sparen.



Wenn du deine beiden Platten in zu einem Storage Space mit Spiegelung zusammenführst, hat es dann deine gewünschte Funktion.
Bei einer Platte kannst du aber immer noch Fehler erkennen...
Ich weiß nicht wie es bei ReFS ist bei ZFS ist es aber so dass die Metadaten für Datein ohnehin doppelt vorhanden sind (sogar bei Pools nur aus einer Platte) und Daten fürs Dateisystem sind sogar 3fach vorhanden auf der Platte. Sprich von Metadaten existiert eine Kopie mehr als für die Daten selbst. Und beim Dateisystem sogar noch ne weitere Kopie.

Wenn ReFS ähnlich arbeitet hätte man hier also auch mit einer einzelnen Platte Vorteile nur die Dateien selber können dann nicht repariert werden, Metadaten aber schon

Chkdsk kann aber mehr als nur nach Fehlern im FS zu suchen. Es kann auch nach Fehlern auf dem Datenträger suchen und defekte Sektoren ummappen. Bei ReFS verlässt man sich auf die Funktion vom FS. Ich habe selbst schon mal erlebt, dass sich ein Datenträger wegen defekt am ReFS nicht mehr ansprechen lies. Ohne eine Datensicherung (die man haben sollte) wären die Daten jetzt futsch während man mit NTFS entweder mit Chkdsk oder diversen Tools bestimmt noch fast alles hätte sichern können.
Seh ich anders, ein perfektes Dateisystem sollte Tools wie chkdsk gar nicht benötigen sondern selber alles nötige schon mitbringen und erst dann aussteigen wenn die Daten wirklich zerstört sind so sehr dass auch wiederherstellungstools nichts mehr bringen würden.
Irgendwelche Tools die noch Daten aus einem kaputten FS ziehen können zeigen eigentlich nur eins nämlich dass das FS nicht wirklich durchdacht ist, weil es das eben selber nicht kann.

Obendrein: Defekte Sektoren ummappen das macht der Controller in deinem Datenträger, damit hat das FS nichts zu tun. Bei SSDs ändern sich die Sektoren wegen Wear Leveling sowieso jedesmal womit eine solche FUnktion im FS total unnütz wäre.
 
Zuletzt bearbeitet:
Bogeyman schrieb:
Bei einer Platte kannst du aber immer noch Fehler erkennen....

Schon aber weshalb sollte man?

NTFS - Datei ist beschädigt, Inhalt wird trotzdem wiedergegeben.
ReFS 1P - Datei ist beschädigt, ReFS sagt "Error" und sperrt den Zugriff

Es gibt Daten, bei denen es wichtig ist keine fehlerhaften Dateien zu lesen. Für eine private Filme, Musik, Bilder, Dokumentensammlung ist aber eine leicht beschädigte Datei meistens besser als gar keine.

Deshalb habe ich auch bereits erwähnt. ReFS hat Gründe und Nischen. Es ist aber kein System für die breite Masse und kein Ersatz für NTFS.

Bogeyman schrieb:
Wenn ReFS ähnlich arbeitet hätte man hier also auch mit einer einzelnen Platte Vorteile nur die Dateien selber können dann nicht repariert werden, Metadaten aber schon

Was nützen mir die Metadaten (Verzeichnisstruktur), wenn ich auf keine der Dateien mehr zugreifen kann?

Bogeyman schrieb:
Seh ich anders, ein perfektes Dateisystem.....

...gibt es nicht! Wenn etwas schief gehen kann, geht etwas schief und sei es "nur", dass man aus "Versehen" den falschen Datenträger formatiert hat und natürlich "gerade" keine aktuelle Sicherung hat.

Mit NTFS ist das dank unzähliger Tools kein Beinbruch. Mit ReFS sind die Daten weg.

Bogeyman schrieb:
Obendrein: Defekte Sektoren ummappen das macht der Controller in deinem Datenträger.

Welchen Controller meinst du? Festplattencontroller? Dieser kann nur Fehler erkennen wenn er zufällig über einen beschädigten Block drüber fährt und diesen nicht lesen kann. Chkdsk /r überprüft den gesamten Datenbereich und bringt den Controller erst dazu fehlerhafte Blöcke auf Hardwareebene umzumappen während, es versucht die Fehler auf FS Ebene zu reparieren.

Klar könnte man alternativ per SMART einen vollständigen Scan ansetzen und sich auf die Fähigkeiten zur "Selbstreparatur" vom Betriebssystem verlassen. Aus Erfahrung kann ich sagen, das es in die Hose gehen kann und wird.
 
Zuletzt bearbeitet:
Was nützen mir die Metadaten (Verzeichnisstruktur), wenn ich auf keine der Dateien mehr zugreifen kann?
Weil die Verzeichnisstruktur nunmal wichtiger ist. Findest du es ist ein Mehrwert wenn du an deine Daten nicht mehr rankommst weil das Dateisystem nen Fehler hat oder die Metadaten obwohl deine Dateien selbst noch in Ordnung sind?

Du benutzt dann checkdisk. Ich mit ZFS muss hingegen gar nichts machen weil das Dateisystem diesen Fehler selbstständig beheben kann.. Du siehste den Unterschied

...gibt es nicht! Wenn etwas schief gehen kann, geht etwas schief und sei es "nur", dass man aus "Versehen" den falschen Datenträger formatiert hat und natürlich "gerade" keine aktuelle Sicherung hat.
Oh mit NTFS brauchst du da extra tools in so einem Fall? Mit ZFS brauche ich das nicht, das spuckt ne Warnmeldung aus und repariert die Bereiche die du einen falsch gestarteten Formatierungvorgang überschrieben wurden.
Es sind nur die Daten weg die tatsächlich überschrieben wurden. Die kann checkdisk aber auch nicht wieder herzaubern.

Welchen Controller meinst du? Festplattencontroller? Dieser kann nur Fehler erkennen wenn er zufällig über einen beschädigten Block drüber fährt und diesen nicht lesen kann. Chkdsk /r überprüft den gesamten Datenbereich und bringt den Controller erst dazu fehlerhafte Blöcke auf Hardwareebene umzumappen während, es versucht die Fehler auf FS Ebene zu reparieren.
Dazu haben CoW Dateisysteme den sogenannten Scrub. Und auch hier kann ZFS mehr als checkdisk und NTFS: Denn es kann jeden Block überprüfen weil es für jeden Block Prüfsummen gibt. Checkdisk kann hier nur sehr begrenzt helfen, weil es unmengen an Fehlern nicht erkennen kann weil es nicht weiß wie die Dateien aussehen müssen. Es kann nur Fehler im Dateisystem erkennen usw.

Es gibt Daten, bei denen es wichtig ist keine fehlerhaften Dateien zu lesen. Für eine private Filme, Musik, Bilder, Dokumentensammlung ist aber eine leicht beschädigte Datei meistens besser als gar keine.
Ist so auch nicht richtig. Auch ein Bild kann aufgrund eines einzelnen Bits schon kaputt sein. ZFS oder allgemein prüfsummen können das aber erkennen, und dich warnen und du kannst die Datei aus dem Backup wieder herstellen. checkdisk kann hier auch nix machen.

Und nein checkdisk kann hier auch nix wiederherstellen, denn auch wenn nur 1 bit umgekippt ist, so ist der ganze Block im Eimer. Du hast keine Möglichkeit herauszufinden an welcher Stelle das Bit gekippt ist

Im Grunde ist checkdisk bei solchen Dateisystemen schon integriert, und nicht nur das, die Möglichkeiten sind auch noch weitaus mächtiger und größtenteils komplett automatisiert.

Schon aber weshalb sollte man?

NTFS - Datei ist beschädigt, Inhalt wird trotzdem wiedergegeben.
ReFS 1P - Datei ist beschädigt, ReFS sagt "Error" und sperrt den Zugriff
Weil du so die Chance hast beurteilen zu können, wenn sowas zu oft auftritt dass vielleicht deine Platte langsam den Geist aufgibt. Das sind obendrein auch Fehler die sich nicht zwangsweise auch in schlechten Smart Werten wiederspiegeln müssen. Sprich die Platte kann im SMART völlig okay aussehen, liefert aber trotzdem immer mehr und mehr falsche Werte

Es ist aber kein System für die breite Masse und kein Ersatz für NTFS.
NTFS gehört ins Museum...
Auf Prüfsummen hat man damals nur verzichtet weil die Rechenpower nicht da war und die Datenträger größen hatten wo solche Fehler sehr unwarscheinlich waren. Durch größere Platten und CPUs wo die berechnungen gar nicht mehr ins Gewicht fallen sind diese Dinge aus den 80er Jahren längst überholt.

Auch CoW kann NTFS nicht. Sprich du musst nach jedem Crash das Dateisystem überprüfen. Auch das ist bei einem CoW Dateisystem nicht der Fall.

Mit NTFS ist das dank unzähliger Tools kein Beinbruch. Mit ReFS sind die Daten weg.
Die Schlussfolgerung die du daraus ziehst ist falsch. Denn du betrachtest gar nicht den Fall dass wenn die Daten mit ReFS weg sind, sie mit NTFS wirklich noch wiederherstellbar gewesen wären.
ReFS ist wesentlich robuster und ich habe mich auch mit NTFS und Checkdisk schon oft herum geschlagen. Sehr oft "repariert" Checkdisk zwar das Dateisystem, opfert dafür aber die betroffenen Datein, welche dann ebenfalls weg sind.

Ob deine Bilddateien noch in Ordnung sind das kannst du nur anhand von Prüfsummen kontrollieren, da hast du mit NTFS und Checkdisk keinerlei Chance. Der Unterschied zu ZFS und ReFS ist eben dass die das ganze im Hintergrund machen.
 
Zuletzt bearbeitet:
Bogeyman schrieb:
Die Schlussfolgerung die du daraus ziehst ist falsch.

Ob deine Bilddateien noch in Ordnung sind das kannst du nur anhand von Prüfsummen kontrollieren, da hast du mit NTFS und Checkdisk keinerlei Chance. Der Unterschied zu ZFS und ReFS ist eben dass die das ganze im Hintergrund machen.

Die Schlussfolgerung die ich gezogen habe ist zu 100% richtig.

ReFS dort gut WO es selbsttätig Daten reparieren kann - in einem Spiegel oder Stripeset mit Storage Spaces. Ebenfalls eignet es sich seit Server 2016 für Hyper-V Dateien WENN sowieso die Maschinen auf einen Backup Server gespiegelt werden. Den dritten Anwendungsfall hat der TE genannt. Er MÖCHTE explizit wissen wenn eine Datei beschädigt ist.

Für die Masse ist ReFS damit trotzdem nicht geeignet und andere Dateisysteme bieten sind unter Windows sowieso nicht an.

Nach dem JETZIGEN Stand der Technik ist jegliche Wiederherstellung von Daten(ohne eine Datensicherung), beim Einsatz von ReFS schwierig bis unmöglich und ich rede aus bitterer Erfahrung, nachdem ein Kollege in der Firma vermutlich so gedacht hat wie du und erst letztlich ein Kunde, nach einem Raidfehler, sich von ein paar Tagen Arbeit verabschieden "durfte".
https://www.krollontrack.de/blog/refs-was-bedeutet-es-und-wie-funktioniert-es/3203

Ein zusätzliches Problem teilt sich ReFS ebenfalls mit diversen anderen Linuxoiden Dateisystemen. Praktisch keine Datensicherungssoftware kommt mit solchen "Sonderlingen" zurecht. Mal eben einzelne Dateien aus einem Image zurückzusichern ist damit unmöglich.

Bogeyman schrieb:
NTFS gehört ins Museum...

NTFS ist so aktuell wie es nur sein kann und beherrscht noch immer wesentlich mehr wie alle anderen gängigen Dateisysteme.

https://en.wikipedia.org/wiki/NTFS
 
Zuletzt bearbeitet:
NTFS ist so aktuell wie es nur sein kann und beherrscht noch immer wesentlich mehr wie alle anderen gängigen Dateisysteme.

https://en.wikipedia.org/wiki/NTFS

Ähm und dein Link hat nichts mit deinem Argument zu tun. Du sagst es ist so aktuell wie es sein kann. Das ist schonmal Murks weil ReFS deutlich jünger und aktueller ist. Ebenso was soll es mehr beherrschen? Der Link gibt keine Auskunft ist daher Schwachsinn.


Nach dem JETZIGEN Stand der Technik ist jegliche Wiederherstellung von Daten(ohne eine Datensicherung), beim Einsatz von ReFS schwierig bis unmöglich und ich rede aus bitterer Erfahrung, nachdem ein Kollege in der Firma vermutlich so gedacht hat wie du und erst letztlich ein Kunde, nach einem Raidfehler, sich von ein paar Tagen Arbeit verabschieden "durfte".
Ja und weißte auch wieso? Weil du mit der Annahme ran gehst man müsste generell Tools einsetzen um Daten aus Dateisystemen zu extrahieren.
Wieso muss man das denn? Richtig, weil das Dateisystem es nicht kann.
Dank neuerer Dateisysteme fällt das Weg. Ebenso wie Checkdisk wegfällt. Sie werden einfach nicht mehr benötigt.
Und ja man kann auch ne Platte mit ReFS formatieren, sie aus dem Fenster schmeißen und dann sagen Datenwiederherstellungssoftware kann mit ReFS nix anfangen und deswegen ist alles blöd.

Nur die Schlussfolgerung ist falsch

Er MÖCHTE explizit wissen wenn eine Datei beschädigt ist.
Wo sind die Personen die sich nicht für ihre Daten interesieren? Wenn dir der Zustand der Daten, oder allgemein die Daten egal sind dann kannste NTFS nehmen, weil du es da erst merkst wenn die Datei sich nicht mehr öffnen lässt. Da kannste soviel chechdisken wie du willst, es kann viele Fehler nicht finden weil es das technisch einfach nicht kann weil es nicht weiß wann die Datei defekt ist und wann nicht.

erst letztlich ein Kunde, nach einem Raidfehler, sich von ein paar Tagen Arbeit verabschieden "durfte".
Aha und das Protokoll des Gutachters fügst du jetzt gleich noch ein welches beweist dass bei einem Raid und NTFS der Kunde seine Daten noch hätte?
Du hast keinen Schimmer davon was passiert ist. Werfe google an und du wirst zig Fälle finden wo Leute mit Raid und NTFS Daten verloren haben. Und in wiefern ist ReFS jetzt schlechter?
Ich vergaß, weil Software daran scheitert Datenwiederherzustellen, die man mit dem neuen Dateisystem nicht braucht?
Sorry das Argument ist in etwa so nachvollziehbar als ob beschwert man sich bei nem Elektroauto darüber dass der Tankdeckel fehlt und man nicht mehr tanken kann.

Diese Tools werden obsolet mit den neueren Dateisystemen, DAS ist die Idee dahinter.

Mir fällt absolut nichts ein wo NTFS im Hinblick der Datensicherheit besser wäre als beispielsweise ZFS. Und das grundsätzliche Konzept hinter ReFS ist mit dem von ZFS und btrfs identisch (außer deiner gebliebten Tools die nicht mehr funktionieren damit, wo du dir aber offenbar gar nicht die Frage stellst wieso du sie überhaupt nutzen musst). Du stellst du nur fest du vermisst sie, hinterfragst aber nicht ob sie überhaupt noch benötigt werden.

Was macht dich so sicher dass du mit einem Tool überhaupt noch hättest Daten wiederherstellen können von ReFS? Du weißt es doch nichtmal... Denkst aber offenbar wenn das Tools funktioniert dann hätte ich Daten wieder herstellen können.
Das sind mir zuviele "hättest".
Man kann darüber streiten wie ausgereift es im Moment ist. Gilt aber nur für ReFS, ZFS ist sehr ausgereift.
Dass solche Tools generell nicht mehr benötigt werden, egal ob ReFS, btrfs oder ZFS erachte ich eher als normal aufgrund der höheren Zuverlässigkeit des Dateisystems an sich und der integrierten "Selbstheilungs"-Fähigkeiten.

Zumal auch kaum ein Mehrwert vorhanden sein dürfte wenn wir mal ne Datenbank nehmen die Widerhergestellt werden konnte durch solche Tools, aber völlig offen ist an welchen Stellen sie nun kaputt/verändert ist.
Davon hat man auch nichts.

Im folgenden ist ein Foto zu sehen wo nur ein einzelnes Bit umgedreht wurde:

https://blog.payperhost.com/wp-content/uploads/2015/08/bit-rot.jpg

Aber hey wen interesiert das schon ob die Daten noch so sind wie sie eins mal waren wenn man nur eine Platte hat.
 
Zuletzt bearbeitet:
Bogeyman schrieb:
Ja und weißte auch wieso? Weil du mit der Annahme ran gehst man müsste generell Tools einsetzen um Daten aus Dateisystemen zu extrahieren.

Ich lebe in der Realität und diese ist nun mal so.

Schon die Tatsache das diverse Datensicherungsprogramme mit ReFS nichts anfangen können ist ein Auschusskriterium, ebenso die nur dürftige Unterstützung unter Linux und somit diverser Programme wie Clone Drive und Co.
http://www.linux-magazin.de/NEWS/ReFS-for-Linux-erlaubt-Schreibzugriff

Ist deiner Traumwelt mag man solche Programme vielleicht nie brauchen, es reicht aber nur ein kurzer Blick in diesem Forum um schnell festzustellen, dass Leute es immer schaffen ihr Dateisystem zu zerstören oder so zu verseuchen das nur ein Zugriff "von Außen" um die Daten zu sichern sinnvoll ist.

Um meinen geschilderten Fall nochmal zu erklären. Falsch herausgezogene Festplatte in einem Raid System hat zu einen Totalausfall von ReFS geführt. Etwas was man bei NTFS problemlos hätte beheben können hat Daten gekostet weil das System sich eben NICHT selbst reparieren kann, es keine Programme gibt um so eine Beschädigung zu beheben und Windows sowas nur mit einem Fehler im Dateisystem quittiert und keinen Zugriff auf die Daten mehr zulässt.

Von fehlenden Features wie Verschlüsselung auf Dateiebene oder Datendeduplizierung reden wir besser gar nicht erst. Microsoft hat ReFS bewusst für Spezialfälle entwickelt und nicht als Ersatz für NTFS und das wird vermutlich auch noch lange so bleiben.
https://blogs.technet.microsoft.com...-does-refs-replace-ntfs-when-should-i-use-it/

So wie ReFS derzeit ist und so wie es unter Windows implementiert wurde hat es eben zig Nachteile, aber nur in spezialfällen Vorteile und um mehr geht es in dieser Diskussion nicht. Verstehe nicht wo du deine ZFS Vergleiche herholst und was die mit dem Thema zu tun haben sollen. ZFS mag toll sein, BTFRS bestimmt noch besser, aber beide machen ReFS nicht zu einem besseres Dateisystem für Windows.

Bogeyman schrieb:
Das sind mir zuviele "hättest"..

Ich arbeite seit 15 Jahren in der IT Branche. Ich weis was man braucht und wie man Daten repariert wenn mal wieder der DAU zugeschlagen hat und ReFS wäre in keinem der Fälle förderlich gewesen. Derzeit kann man da großenteils, genauso wie bei verschlüsselten Datenträgern, abwinken und den Kunden mit wenig Hoffnung auf professionelle Datenrettungsunternehmen verweisen oder mit "Pech gehabt" abspeisen.

Ich kann letztlich jeden der selbst Experimente mit ReFS durchführen möchte auf diesen Absatz verweisen und man kann ihn auch nicht oft genug wiederholen.

These are exactly the failures that ReFS can detect using checksums. Once ReFS detects such a failure, it interfaces with Storage Spaces to read all available copies of data and chooses the correct one based on checksum validation. It then tells Storage Spaces to fix the bad copies based on the good copies. All of this happens transparently from the point of view of the application. If ReFS is not running on top of a mirrored Storage Space, then it has no means to automatically repair the corruption. In that case it will simply log an event indicating that corruption was detected and fail the read if it is for file data. I’ll talk more about the impact of this on metadata later.

Checksums (64-bit) are always turned on for ReFS metadata, and assuming that the volume is hosted on a mirrored Storage Space, automatic correction is also always turned on. All integrity streams (see below) are protected in the same way. This creates an end-to-end high integrity solution for the customer, where relatively unreliable storage can be made highly reliable.
https://blogs.msdn.microsoft.com/b8...next-generation-file-system-for-windows-refs/

Es bedeutet nicht mehr und nicht weniger, als das ReFS ohne Storage Spaces eine Zeitbombe ist, von der man außerhalb der paar Fälle, für die ReFS entwickelt wurde, die Finger lassen sollte und die "Selbstreparatur" sich NUR auf den Einsatz zusammen mit SS bezieht. Nichts anderes habe ich aber bereits mehrfach geschrieben.
 
Zuletzt bearbeitet:
Ist deiner Traumwelt mag man solche Programme vielleicht nie brauchen, es reicht aber nur ein kurzer Blick in diesem Forum um schnell festzustellen, dass Leute es immer schaffen ihr Dateisystem zu zerstören oder so zu verseuchen das nur ein Zugriff "von Außen" um die Daten zu sichern sinnvoll ist.
Und diese Leute nutzen alle ReFS, ja? Und warscheinlich hast du auch schon die letzten 15 Jahre lang schlechte Erfahrungen mit ReFS gemacht, ist dies ebenfalls korrekt?

Und ist es auch korrekt das NTFS alle möglichen bitfehler erkennen kann, komplett ohne irgendwelche Prüfsummen?

In that case it will simply log an event indicating that corruption was detected and fail the read if it is for file data.
Korrekt, wo hingegen dein tolles Backupprogramm eine völlig korrupte Datei sichern würde OHNE(!) dass du davon auch nur irgendetwas schecken würdest...
Muss ja ein riesen Vorteil sein;)

die Finger lassen sollte und die "Selbstreparatur" sich NUR auf den Einsatz zusammen mit SS bezieht.
Auf die (User)Daten bezogen, aber NICHT auf die relevanten Blöcke für das Dateisystem an sich.

Überschreibe doch die ersten 10GB einer sagen wir mal 500GB Platte welche mit NTFS formatiert wurde "ausversehen". Wie kommst du an deiner Daten wieder heran? Richtig, ohne Tool überhaupt nicht.
Bei ZFS kann der Datenträger einfach gemountet werden genauso wie als wäre er vollkommen in Ordnung ohne dass du irgendwelche Tools bemühen musst.

Bei ReFS ist es bei entsprechender Implementierung genau das gleiche.

Falsch herausgezogene Festplatte in einem Raid System hat zu einen Totalausfall von ReFS geführt. Etwas was man bei NTFS problemlos hätte beheben können hat Daten gekostet weil das System sich eben NICHT selbst reparieren kann, es keine Programme gibt um so eine Beschädigung zu beheben und Windows sowas nur mit einem Fehler im Dateisystem quittiert und keinen Zugriff auf die Daten mehr zulässt.
Wohingegen gar nicht klar ist nur weil es bei EINEM Fall so war, woran es überhaupt lag und ob du in DIESEM Fall mit NTFS irgendwas hättest retten können. Das weißt du nicht, du vermutest es nur.

Und nochmals diese "Tools" machen nur Dinge die das eben nicht mehr so aktuelle und nicht ganz so tolle Dateisystem einfach nicht kann. Selbst dass die Datenintegrität bei einem Stromausfall nichtmal gewährleistet ist bei einem Dateisystem wie NTFS, zeigt einfach wie überholt es mittlerweile ist.
Apple setzt ebenfalls ein modernes Filesystem ein heute und nicht etwas aus den Anfängen der Zeit des PCs.

Schon die Tatsache das diverse Datensicherungsprogramme mit ReFS nichts anfangen können ist ein Auschusskriterium, ebenso die nur dürftige Unterstützung unter Linux und somit diverser Programme wie Clone Drive und Co.
Krasse Logik, wirklich, nicht. Wieso können "diverse" Programme damit nix anfangen und wieso sieht die Unterstützung außerhalb von Windows schlecht aus? KÖNNTE das vielleicht ganz eventuell etwas damit zu tun haben weil der Quellcode nicht freizügänglich ist? Ganz eventuell vielleicht?

Aber nun gut ein nicht Quelloffenes Dateisystem ist für dich also ein Nachteil, sodass du eher bereit bist etwas veraltetes einzusetzen welches in Punkto Datensicherheit deutlich unzuverlässiger ist aufgrund seiner kompletten Architektur? Immerhin haste eh kein Plan was du an Daten da letztendlich ausliest weil sich das Dateisystem ja gar nicht darum scherrt ob es die Daten liefert die du eins abgespeichert hast.

Allerdings sind das laut deinen Aussagen ja eh "speziellfälle" wo es wichtig sein könnte dass die Daten eben nicht korrupt sind.
Und weißt du was der Spezialfall ist? Es sind sämtliche Daten. Bei sämtlichen Daten ist es wichtig ob sie noch in Ordnung sind oder nicht grade wenn wir um Archivierung sprechen.

Ergo ist NTFS für Archivierung bei weitem nicht die beste Wahl eben aufgrund von fehlenden Prüfsummen.

Microsoft hat hier einfach gepennt weil die Konkurrenz längst dabei ist auf CoW Dateisysteme umzustellen. Apple ist mit APFS auch schon weiter, zumindest ist es schon für den Kunden nutzbar.
 
Zuletzt bearbeitet:
Bogeyman schrieb:
Auf die (User)Daten bezogen, aber NICHT auf die relevanten Blöcke für das Dateisystem an sich.

Überschreibe doch die ersten 10GB einer sagen wir mal 500GB Platte welche mit NTFS formatiert wurde "ausversehen". Wie kommst du an deiner Daten wieder heran? Richtig, ohne Tool überhaupt nicht.
Bei ZFS kann der Datenträger einfach gemountet werden genauso wie als wäre er vollkommen in Ordnung ohne dass du irgendwelche Tools bemühen musst.

Bei ReFS ist es bei entsprechender Implementierung genau das gleiche.

Ich denke du kannst lesen und verstehen. Dann lies dir nochmal die von mir verlinkte Beschreibung von ReFS durch oder zumindest den Absatz wo auf die "Selbstheilung" vom ReFS hingewiesen wird, lass bitte wieder die an dieser Stelle irrelevanten Vergleiche mit ZFS und behaupte bitte keinen Unsinn der von ReFS so nicht implementiert wird.

Ich kann aber gerne nochmal für dich die entscheidenden Sätze zusammenfassen.

If ReFS is not running on top of a mirrored Storage Space, then it has no means to automatically repair the corruption. In that case it will simply log an event indicating that corruption was detected and fail the read if it is for file data.

Checksums (64-bit) are always turned on for ReFS metadata, and assuming that the volume is hosted on a mirrored Storage Space, automatic correction is also always turned on. All integrity streams (see below) are protected in the same way.
https://blogs.msdn.microsoft.com/b8...next-generation-file-system-for-windows-refs/

Mal im Klartext.

OHNE SS kann sich ReFS NICHT SELBST REPARIEREN. Ein Datenträgerfehler bedeutet den Tod für das Dateisystem, wie selbst erlebt und geschildert. Mag vielleicht nicht bei jedem kleinsten Fehler geschehen ist aber eine tickende Zeitbombe, die so mit NTFS nicht vorkommt. Unter NTFS wäre es zudem noch meistens problemlos möglich, selbst ohne jegliche Verzeichnisstruktur Daten zu retten. Dank fehlender Werkzeuge und auch dank Copy on Write kannst du das mit ReFS praktisch vergessen.

Bleibt der Einsatz von ReFS dafür, wofür es gemacht wurde. Für Storage Spaces, für Datenträger mit vielen Dateien (>Milliarde), für Hyper-V Hosts mit Replikation und eben dort wo man eine hohe Datenintegrität benötigt. Damit ist es nur nicht ansatzweise ein Ersatz für NTFS, genauso wenig wie ZFS, das du so gerne anführst, EXT4 oder XFS ersetzt.
 
Zuletzt bearbeitet:
Vielen dank für die vielen Antworten!

Das ist ja wirklich kein leichtes Thema. Aber ReFS ist ja (mal abgesehen vom Server betrieb) dann ja eigentlich recht enttäuschend. Selbst ohne Integrity Stream dachte ich das ReFS zumindest deutlich stabiler als NTFS sei. Doch wenn die Metadaten sowieso nur 1x gespeichert werden und eine Reparatur der Metadaten nur mit Spiegel betrieb möglich ist, ist das System ja effektiv kein bisschen stabiler als NTFS. Da ist ZFS mit dem mehrmaligen Abspeichern der Metadaten ReFS ja deutlich voraus.

Kurz gesagt wäre der einzige Vorteil den ReFS hätte, die Möglichkeit den Integrity Stream zu nutzen und so über defekte Dateien informiert zu werden? Ohne Integrity Stream oder Spiegel hat es ja keinen einzigen Vorteil zu NTFS was die Stabilität angeht?

Wobei ich sogar gelesen hatte das man als "Defekt" erkannte Dateien mir ReFS nicht mal löschen kann? Stimmt das?

Da ist die Platten sowieso verschlüssele kann ich ja so oder so keine Wiederherstellungsprogramme nutzen. Hier hätte ReFS für mich keinen Nachteil.
 
Paddii schrieb:
Kurz gesagt wäre der einzige Vorteil den ReFS hätte, die Möglichkeit den Integrity Stream zu nutzen und so über defekte Dateien informiert zu werden? Ohne Integrity Stream oder Spiegel hat es ja keinen einzigen Vorteil zu NTFS was die Stabilität angeht?

Wobei ich sogar gelesen hatte das man als "Defekt" erkannte Dateien mir ReFS nicht mal löschen kann? Stimmt das?

Ganz so einfach oder schlimm ist es nicht und wenn man bestimmte Anforderungen stellt oder mit den Nachteilen umgehen kann, bietet ReFS ein paar Features die NTFS eben nicht hat.

Integrität ist definitiv ein solcher Stichwort den "Bogeyman" mehrfach in den Raum geworfen hat. Wenn du deine Daten regelmäßig sicherst und vermeiden möchtest möglicherweise bereits defekte Daten zu sichern ist ReFS etwas für dich, selbst wenn du kein Storage Space verwenden willst oder kannst.

Defekte Dateien lassen sich auch durchaus löschen. Das Ganze wird in meinem Link auch genau erklärt.

For these cases where the volume gets corrupted, ReFS implements “salvage,” a feature that removes the corrupt data from the namespace on a live volume. The intention behind this feature is to ensure that non-repairable corruption does not adversely affect the availability of good data. If, for example, a single file in a directory were to become corrupt and could not be automatically repaired, ReFS will remove that file from the file system namespace while salvaging the rest of the volume. This operation can typically be completed in under a second.

ReFS führt zudem ein Copy on Write im Gegensatz zu NTFS was auf Journalen basiert. Damit können Beschädigungen vermieden werden wenn ein System abstürzt oder es einen Stromausfall gibt, während auf dem Datenträger geschrieben wird. Nur sind Abstürze und Stromausfälle nicht unbedingt etwas, was man jeden Tag erlebt und bei einer Platte die als Datengrab dient, ist die Wahrscheinlichkeit für so einen Fall eh gering.

Es bleibt die Frage wieso du keine Storage Spaces einsetzen möchtest. Damit hättest du auf jeden Fall einige Vorteile was die Stabilität UND Integrität anbetrifft, aber auch mit einem regelmäßigen Backup wärst du auf der sicheren Seite. Kein noch so tolles Dateisystem kann von Ransomware schützen, eine offline Datensicherung ist sowieso Pflicht.
 
Zuletzt bearbeitet:
xexex schrieb:
Ich denke du kannst lesen und verstehen. Dann lies dir nochmal die von mir verlinkte Beschreibung von ReFS durch oder zumindest den Absatz wo auf die "Selbstheilung" vom ReFS hingewiesen wird, lass bitte wieder die an dieser Stelle irrelevanten Vergleiche mit ZFS und behaupte bitte keinen Unsinn der von ReFS so nicht implementiert wird.

Ich kann aber gerne nochmal für dich die entscheidenden Sätze zusammenfassen.
Ja guck doch mal was da steht. "File Data". Also bezieht sich das gar nicht auf die MetaDaten und Daten fürs Dateisystem weil auch hier bei einer einzelnen Platte kopien bestehen, die es bei NTFS nicht gibt. Du musst auch schon genau lesen was du da zitierst.

Doch wenn die Metadaten sowieso nur 1x gespeichert werden und eine Reparatur der Metadaten nur mit Spiegel betrieb möglich ist, ist das System ja effektiv kein bisschen stabiler als NTFS. Da ist ZFS mit dem mehrmaligen Abspeichern der Metadaten ReFS ja deutlich voraus.
Wo steht das denn dass Metadaten nur einmal gespeichert werden? Bei ZFS ist das nicht so (das kann ich zu 100% sagen) und selbst das von xexex gebrachtet Zitat zu ReFS sagt das auch nicht aus sondern bezieht sich eben nur auf die User Daten was bei einer Platte so nunmal technisch bedingt ist. Das ist schon ein großer Vorteil, eben weil es das Dateisystem so nicht ganz so einfach zerschießen kann.

Nur sind Abstürze und Stromausfälle nicht unbedingt etwas, was man jeden Tag erlebt und bei einer Platte die als Datengrab dient, ist die Wahrscheinlichkeit für so einen Fall eh gering.
Dennoch bleibt es ein Vorteil, weil du eben bei einem Absturz/Stromausfall jedesmal das Dateisystem ansonstn überprüfen müsstest. Ein Vorgang den viele abbrechen weil sie in solchen Fällen meist besseres zu tun haben als zu warten und so ein Test dann auch nicht nachgeholt wird vom User

Ohne Integrity Stream oder Spiegel hat es ja keinen einzigen Vorteil zu NTFS was die Stabilität angeht?
IS bezieht sich auf die Userdaten, nicht aufs Filesystem das ist auch so schön geschützt. Würde es aber denoch auch für UserDaten aktivieren, egal ob einzelne Platte oder SS, weil es imo wichtig ist über Fehler informiert zu werden selbst wenn sie dann aufgrund eines 2. Spiegels nicht automatisch repariert werden können.
 
Zuletzt bearbeitet:
Zurück
Oben