News Windows 11: Neues Dateisystem ist bis zu 94 Prozent schneller

[PCGH_Sven]

Windows 11 24H2 macht das für Hochleistungsrechner vorgesehene Dateisystem Microsoft ReFS ("Resilient File System") auch für Endanwender verfügbar. Damit werden Kopiervorgänge um bis zu 94 Prozent beschleunigt.

Was sagt die PCGH-X-Community zu Windows 11: Neues Dateisystem ist bis zu 94 Prozent schneller

Bitte beachten: Thema dieses Kommentar-Threads ist der Inhalt der Meldung. Kritik und allgemeine Fragen zu Online-Artikeln von PC Games Hardware werden hier gemäß der Forenregeln ohne Nachfrage entfernt, sie sind im Feedback-Thread besser aufgehoben.

 

[Blackfirehawk]

Klingt ja per se nett und sinnvoll..

Aber das man von dem Datei system nicht booten kann macht es für den Endanwender irgendwie komplett obsolet

 

[Takei Naodar]

Hört sich für mich einfach nach CoW an. Gibt es schon lange.
Fraglich ist für mich der Punkt "automatische Korrektur von erkannten Datenfehlern". Wie soll das gehen? Entweder mit einem Hamming code ähnlichen Konstrukt oder man muss die Datei mehrfach speichern und über Checksummen abgleichen, also im Regelfall ein Software Raid über mehrere Festplatten.

 

[Incredible Alk]

Fraglich ist für mich der Punkt "automatische Korrektur von erkannten Datenfehlern". Wie soll das gehen?

 

[Alter_Zocker]

Ohne jetzt die Spezifikation von ReFS zu kennen, würde ich mal aus dem bisherigen UseCase als Server-FS folgern, dass der Fokus bei diesem File System eher auf hohe Zuverlässigkeit und Datenintegrität gerichtet ist und weniger auf hohe PErformance. Und ein besonders flottes "Data-Copy" ist jetzt auch nicht Alles, was so ein FS bewältigen muss...

 

[ΔΣΛ]

Da Speichermedien mit ReFS-Dateisystem nicht gebootet werden können, wird das "Resilient File System" den aktuellen NTFS-Standard nicht auf Systemlaufwerken ablösen, sondern als Speziallösung für Entwickler dienen.

Ohne, sehr schade, also bleibt NTFS bei uns wohl erhalten, auf sehr lange Zeit.

 

[Schinkennudel]

Anhang anzeigen 1471120

Jetzt hört es sich ja noch mehr nach BTRFS an. Gibt es dafür auch Snapshots, optionale Kompression und Subvoliums?

 

[Neuer_User]

Damit werden Kopiervorgänge um bis zu 94 Prozent beschleunigt.

Wenn ich mir die Messwerte anschaue und NTFS mit Dev Drive vergleiche, dann ist das ja ganz im Gegensatz zum Titel des Artikels nicht knapp eine Verdopplung der Geschwindigkeit, sondern man braucht anstatt 100% Zeit bei großen Dateien nur mehr etwas um 6-8% der Zeit, spart also maximal 92-94% ein. Das ist also je nach Dateigröße eine Verfünffachung- bis Verzwanzigfachung der Geschwindigkeit.

Respekt. Das wird gerade in KI Zeiten mit explodierneden Datenmengen hilfreich sein!

 

[Incredible Alk]

Jetzt hört es sich ja noch mehr nach BTRFS an. Gibt es dafür auch Snapshots, optionale Kompression und Subvoliums?

Optionale Kompression iirc ja, den Rest weiß ich nicht. Ich glaube aber nicht, dass das Standard ReFS Subvolumes (in Windows) kann.

Respekt. Das wird gerade in KI Zeiten mit explodierneden Datenmengen hilfreich sein!

Das Problem an dem Vergleich ist, dass es nur in einem sehr speziellen Fall solche Geschwindigkeitszuwächse gibt der so fast nie auftritt. Es geht hier sehr vereinfacht gesagt darum, dass ReFS wenn man Daten kopiert in der Lage ist, einfach einen passenden TOC-Eintrag zu erstellen statt die Daten tatsächlich physikalisch zu kopieren. Natürlich geht das sehr viel schneller nur passende Verknüpfungen zu hinterlegen statt tatsächlich GB-weise Daten zu schreiben.
Nur hilft das ausschließlich dann, wenn ich Daten auf dem gleichen Datenträger/Filesystem duplizieren will. UNd die Anwendung ist schon sehr speziell und meistens wollen die Leute das ja auch physikaisch dupliziert haben, entweder als Backup oder um eine Kopie zu haben an der man arbeitet ohne Originaldateien zu ändern - und was passiert dann? Man erstellt die Kopie in 500 Millisekunden und wenn man dann an der (logischen aber nicht physisch vorhandenen) Kopie arbeitet bzw. diese Daten ändert ist ReFS trotzdem nachträglich gezwungen, eine physische Kopie zu schreiben... was dann genauso lange dauert wie bei NTFS.

 

[sterreich]

Naja, COW vs. Journaling FS, nicht gerade neu der Unterschied. Gilt auch nur für "Kopien" innerhalb desselben Mediums. Sobald ich das auf eine andere Partition/Platte/Netzwerk-Share/etc. ziehe ist dieser Geschwindigkeitsboost auch dahin.

Wäre nett wenn man bei sowas die ursprüngliche Quelle der Daten verlinkt (ja ich weiß Tomshardware hat es auch nicht gemacht)

Unlock a new era of innovation with Windows Copilot Runtime and Copilot+ PCs

I am excited to be back at Build with the developer community this year.

blogs.windows.com

Insgesamt klingt es nach einer Lösung die ZFS und BTRFS hinterherhinkt (nona bei 3-7 Jahren Entwicklungsvorsprung) und durch erzwungene NTFS-Kompatibilität gehandicapt wird.
Wird außerhalb von Windows-Servern vermutlich wenig Verwendung finden. Und das auch nur weil Windows nicht (offiziell) mit den besseren Alternativen umgehen kann.

Hört sich für mich einfach nach CoW an. Gibt es schon lange.

Jupp. Microsoft versucht mal wieder bereits existierende Dinge mittels Marketing als Eigenentwicklung zu verkaufen:

Copy-on-write (CoW) linking, also known as block cloning in the Windows API documentation, avoids fully copying a file by creating a metadata reference to the original data on-disk.

Dev Drive and Copy-on-Write for Developer Performance - Engineering@Microsoft

Try out the new Windows Insider release for double-digit build performance wins with a small amount of effort.

devblogs.microsoft.com

 

[RobooeL]

Naja, COW vs. Journaling FS, nicht gerade neu der Unterschied. Gilt auch nur für "Kopien" innerhalb desselben Mediums. Sobald ich das auf eine andere Partition/Platte/Netzwerk-Share/etc. ziehe ist dieser Geschwindigkeitsboost auch dahin.

Wäre nett wenn man bei sowas die ursprüngliche Quelle der Daten verlinkt (ja ich weiß Tomshardware hat es auch nicht gemacht)

Unlock a new era of innovation with Windows Copilot Runtime and Copilot+ PCs

I am excited to be back at Build with the developer community this year.

blogs.windows.com

Insgesamt klingt es nach einer Lösung die ZFS und BTRFS hinterherhinkt (nona bei 3-7 Jahren Entwicklungsvorsprung) und durch erzwungene NTFS-Kompatibilität gehandicapt wird.
Wird außerhalb von Windows-Servern vermutlich wenig Verwendung finden. Und das auch nur weil Windows nicht (offiziell) mit den besseren Alternativen umgehen kann.

Jupp. Microsoft versucht mal wieder existierende Dinge mittels Marketing als Eigenentwicklung zu verkaufen:

Dev Drive and Copy-on-Write for Developer Performance - Engineering@Microsoft

Try out the new Windows Insider release for double-digit build performance wins with a small amount of effort.

devblogs.microsoft.com

Ja is gut.. für Normal user isses neu

 

[Gast1754557804]

Ich bin überzeugt davon, dass es sinnvolle Einsatzgebiete für dieses FS gibt. Nur wird es wohl nicht der Privatkonsument sein.

Einige Dinge hören sich ganz nett an (Transaktionen, Redundante Datenhaltung, größeres Addressvolumen, ...).

Andere wie das schnellere Kopieren von Daten dürften sich für oft eher im Rahmen halten, da die Kosten oft auch auf andere Umstände basieren. Begrenzen tun hier die Limitierungen durch das Bussystem (PCIe), LAN oder auch USB. Und auch Transkationen und redundante Datenhaltung, heute schon durch RAID nutzbar, ersparen z.B. keine Backups und den dafür notwendigen Aufwand und deren Kosten.

Ich sehe hier das "Big Thing" nicht!

 

[PCGH_Sven]

sondern man braucht anstatt 100% Zeit bei großen Dateien nur mehr etwas um 6-8% der Zeit.

Danke dir für den Hinweis. Du hast selbstverständlich absolut recht.

Titel und Fließtext werden in wenigen Minuten entsprechend angepasst.

 

[wurstkuchen]

Und wo liegen jetzt genau die Nachteile, außer dem nicht booten? Es kann ja nicht nur Vorteile geben. Gibt es Risiken zb für Datenverlust beim Kopieren?

 

[Dooma]

Also ich tu mich gerade ein wenig schwer damit zu verstehen wie das genau funktioniert.

Wenn ich damit eine Datei kopiere, dann wird die gar nicht richtig kopiert, sondern nur eine Referenz angelegt zum zuerst angelegten physischem Datenblock?

Was passiert denn wenn dieser beschädigt wird?
Hab ich dann eine kaputte Orignaldatei und eine kaputte Kopie?

Würde das nicht den eigentlichen Sinn warum man eine Kopie von einer Datei macht entgegensprechen?

Was passiert wenn ich die Kopie dann bearbeite und speichere?
Wird dann der Schreibvorgang nachgeholt mit den neuen Daten?
Oder wird dann nur die Abweichung gesichert und der Rest bleibt Referenz?

 

[4thVariety]

Wenn ich damit eine Datei kopiere, dann wird die gar nicht richtig kopiert, sondern nur eine Referenz angelegt zum zuerst angelegten physischem Datenblock?

Ja, im Prinzip ist die Kopie nur eine "Verknüpfung mit" in der Hardwareebene.

Was passiert denn wenn dieser beschädigt wird?
Hab ich dann eine kaputte Orignaldatei und eine kaputte Kopie?

Wenn auf Hardwareebene die Datei futsch ist, nützen Dir auch zwei Einsprungpunkte nichts.
Das System stammt aus dem Serverumfeld, da löst man das mit RAID Varianten und Schattenkopien.
Zumindest für die Eigenen Dokumente sind Schattenkopien auch ein gangbarer Weg, der auch viele Savegame abdeckt. Wenn man ein Backup macht und das in ein unkomprimiertes Zip packt, hat sich der Fall ja ohnehin erledigt. ReFS hat ja nicht nur Referenzieren von Blöcken als Feature, die Antwort auf deine letzte Frage hebelt auch diese Frage komplett aus.

Würde das nicht den eigentlichen Sinn warum man eine Kopie von einer Datei macht entgegensprechen?

Ziel dieses System ist nicht dass man Platz spart wenn man eine Kopie macht als User, sondern dass Dateien die auf natürlichem Wege vielfach in einem System existieren dedupliziert werden. Zum Beispiel wenn eine Unternehmensumgebung User Profile auf einem zentralen Server speichert. Da geht das dann damit los, dass man nicht mehr jeden Link und jede Vorlage der User so oft speichert wie man User hat. Microsoft ist da auch eher die Einsteigerlösung.

Was passiert wenn ich die Kopie dann bearbeite und speichere?

Allein Umbenennen hebelt das System aus, wenn du etwas bearbeitest und speicherst, dann erst recht.

Wird dann der Schreibvorgang nachgeholt mit den neuen Daten?
Oder wird dann nur die Abweichung gesichert und der Rest bleibt Referenz?

Wenn aus zwei identischen Dateien zwei unterschiedliche werden, dann wird gespeichert wie bisher.

Oder wird dann nur die Abweichung gesichert und der Rest bleibt Referenz?

Das macht ReFS nicht auf Ebene einer einzelnen Datei, sondern auf Ebene der gesamten Festplatte. In letzter Instanz wird immer nur die Abweichung gespeichert, auch eine Datenkorrumption ist in vielen (nicht allen) Fälle so eine Änderung die man mit einem Rollback korrigiert bekommt. Immerhin schreiben wir alle nur noch auf Flash, da will man ja auch vermeiden ständig die Zellen zu überschreiben bis sie kaputt gehen.


NTFS ist 30 Jahre alt und ReFS auch schon wieder über 10. Das ist schon ok, wenn wir darauf wechseln.

 

[Takei Naodar]

Anhang anzeigen 1471120

Hört sich für mich wie Btrfs an. Also brauch man doch noch ne Kopie auf ner anderen Partition um die Fehler beheben zu können.

Hab ich dann eine kaputte Orignaldatei und eine kaputte Kopie?

Jap. Denn es ist keine richtige Kopie, denn die würde ja viel länger brauchen um die Daten hin und her zu schieben.
Hat aber auch den Vorteil, dass beim Kopieren kein extra Speicherplatz oder keine extra Schreibzyklen verbraucht werden (außer für die Metadaten).

Ich bin überzeugt davon, dass es sinnvolle Einsatzgebiete für dieses FS gibt. Nur wird es wohl nicht der Privatkonsument sein.

Ich benutz Btrfs schon seit Jahren, das hat eigentlich die gleichen Features. Und es ist schon praktisch, denn durch Checksumming kann man leicht feststellen ob auf der Platte noch alle Sachen integer sind, zum Beispiel für die eigene runtergeladene GoG Bibliothek und vieles anderes mehr. Dadurch lassen sich dann auch Backups prüfen ohne großen besonderen Aufwand. Besonders praktisch wäre es aber für die Windows Platte, da man damit sicherstellen kann, dass alle Daten in Ordnung sind. Schade dass das nicht geht.

 

[Poulton]

ReFS - Das Papiertiger Filesystem von Microsoft. Unangenehme Einschränkungen:
- Finger weg davon auf Hardware RAID, es sei denn der Controller unterstützt flush
- Finger weg davon auf SAN und Cluster Shared Volumes
- keine Unterstützung für Microsoft Offloaded Data Transfer (ODT)
- Windows Updates auf Spielwiese testen. Man hat es durch ein Windows Update schon hinbekommen, die ReFS formatierte Partition als RAW erscheinen zu lassen...

 

[Poulton]

Respekt. Das wird gerade in KI Zeiten mit explodierneden Datenmengen hilfreich sein!

Leider keine wirkliche Beschreibung Seitens Microsoft bzgl. der verwendeten Umgebung und Einstellungen. Da fehlen u.a. sowohl bei ReFS wie auch NTSF Angaben über
- wurde lokal kopiert oder über Netzwerk
- verwendete SMB Version
- war SMB Direct aktiv
-Jumbo Frames ja/nein
- wurde das kopieren via Explorer oder Robocopy gemacht
- wenn mit Robocopy mit welchen Parametern

 

[Raffnek30000]

@Poulton es kann bei einem raid zu problemen kommen? ehrlich gesagt würde ich so ein system nur auf einem raid bei mir nutzen. hahahah lustig...

aber das teil ist mir neu, obwohl es nicht neu ist. in der firma wird es glaube ich auch nicht verwendet.