News Windows 11 erhält ReFS: Microsoft bereitet Update auf das robuste Dateisystem vor

bluedxca93 schrieb:
Es wäre kein Problem das jetzige Berechtigungskonzept auf ext4 abzubilden.Viele Windows Anwendungen nutzen dieses gar nicht so intensiv. Wine kann problemlod windows Anwendungen auf ext4 ausführen, windows würde das auch schaffen. btrfs läuft echnsich gesehn unter windows und ext4 würde auch mit einem angepasstem Berechtigungskonzept funktionieren. Spezielle Dateien lassen sich auch in rinem Image innerhalb des Systems "mounten".Was fehlt ist die Einsicht von Microsoft das ntfs und refs keine sichere Option zum speichern von Dateien sind. FAT Systeme auf Festplatten sind deutlich sicherer als ntfs auf ssds. Nur löschen kann man mit ntfs sicherer.
Berechtigungen sind auch eher ein Ding auf Ebene des Betriebssystems und nicht von Anwendungen[1]. Entsprechend muss sich zum Beispiel auch wine nicht darum kümmern, Windowsanwendungen von irgendwelchen Dateisystemen aus der unixoiden Welt zu laden. Die Windowsanwendungen fordern Daten/Dateien, Wine übersetzt den Zugriff auf die Windowsapi zur passenden API des Hostsystems und das Hostsystem checkt, ob $User entsprechende Rechte auf $Datei hat. Von letzterem bekommt Wine und die Anwendung nichts mit.
Und bedingt ja, man könnte mit ACL (Access-control list) auch etwas stricken, damit Windows und Linux gleichberechtigt auf ext4, BTRFs und ähnlichen ihre Berechtigungen verwalten können. In der Praxis ist das aber in der Regel großer Sackgang. An der Stelle aber hauptsächlich, weil die *nix-Kollegen[2] mit ACLs nicht gescheit umgehen (wollen).

Und das NTFS und ReFS keine sicheren Dateisysteme sein sollen.. Kein Dateisystem ist perfekt, es gibt Annahmen und Randbedingungen unter denen Dateisysteme arbeiten und funktionieren. Abseits davon wird es immer problematisch. Und das FAT gar sicherer sein soll, bei FAT fehlen grundlegende Features, um überhaupt festzustellen, dass irgendwas nicht stimmt. Das Ausbleiben von festgestellten Fehlern ist an der Stelle kein Anzeichen von Sicherheit.

[1] Berechtigungsverwaltung den jeweiligen Anwendungen Userspace zu überlassen wäre auch arg witzlos.
[2] Hier geht es wirklich um die Menschen, die Softwareseite kann das.

Renegade334 schrieb:
Dann muss aber eigentlich nachträglich etwas schief gelaufen sein. Beim Schreiben sollte die Prüfsumme bereits kontrolliert und falls etwas nicht stimmt erneut angefordert werden.
Mir ist auf Anhieb kein Dateisystem bekannt, welches vorsieht Prüfsummen nach dem Schreiben sofort zu verifizieren. Das würde bei HDDs und SSDs einfach viel zu sehr auf die Leistung gehen. Üblich sind eher regelmäßiges Scrubbing.
Allenfalls bei Anwendungen, bei denen die Datenintegrität wirklich wichtig ist, aber da sieht man es dann auf Anwendungsebene vor entsprechende Verifikation zu betreiben.
 
  • Gefällt mir
Reaktionen: Micke und hanfkeks
polyphase schrieb:
Zurück zu ReFS, mit WinFS (war mal für Vista geplant, als es noch Longhorn hieß) hat es nichts zu tun, oder?
Es ist "auch" ein Dateisystem, aber nein hat damit sonst nichts zu tun.
WinFS includes a relational database for storage of information, and allows any type of information to be stored in it, provided there is a well defined schema for the type. Individual data items could then be related together by relationships, which are either inferred by the system based on certain attributes or explicitly stated by the user. As the data has a well defined schema, any application can reuse the data; and using the relationships, related data can be effectively organized as well as retrieved. Because the system knows the structure and intent of the information, it can be used to make complex queries that enable advanced searching through the data and aggregating various data items by exploiting the relationships between them.
https://en.wikipedia.org/wiki/WinFS

Wer "WinFS" haben will, sollte sich Windream anschauen, auch wenn die Software heutzutage noch viel mehr kann.
https://www.windream.com/software/windream-8
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: polyphase
Wichtig wäre mal auch auf die Problematik mit langsam schwächer werdenden Speicherstellen einzugehen.
Naja und bei CPUs und RAM gibts ja auch ECC und andere Schutzmechanismen.
Keine Ahnung wie RAID das mit Checksummen löst aber so viel Leistung wirds dann nicht fressen denk ich mal.
 
Termy schrieb:
Na NTFS ist ja auch gut abgehangen...aber immer noch keine snapshots, kein COW, keine compression...wirkt schon irgendwie etwas angestaubt :D
aber es läuft auf milliarden von rechnern. und läuft und läuft und läuft :D
:D:D
 
ECC haben HDDs auch. Jeder Sektor hat seinen ECC-Bereich - und deswegen brauchte man bei DVD-RAM nicht "Daten nach dem Brennen überprüfen" und muss man das bei HDD auch nicht. ;)
 
Caramon2 schrieb:
Ich nutze Linux um zu lernen, auch per Try&Error (Wie soll man die Grenzen erkennen, wenn man sie nicht überschreitet?). Dabei stoße ich eben auf sowas und teste es aus: Wäre es nicht reproduzierbar, würde ich es nicht behaupten.
Du hast keinerlei Linux-Kenntnisse, bzw. bist du in diesem Bereich hier auf Noob-Level, und philosophierst hier über Linux-Dateisysteme. Du findest XFS besser als EXT4, obwohl du keinerlei Ahnung hast, welches Vorzüge welches Dateisystem hat. BTRFS ist deiner Meinung nach kacke, weil du einfach ein Kasper bist... Das ist meine Meinung. Ich arbeite beruflich als IT-Infrastructure Architect und DevOps in einem Rechencenter. Privat, auf meiner Workstation nutze btrfs auf allen Partitionen, bei denen ich sowohl via Windows als auch Linux zugreifen will (im DualBoot). Sobald man in der Windows-Registry die UID und GID anpasst, gibt es selbst mit Berechtigungen keinerlei Probleme. Das hier Files oder anderes nicht kopiert werden, fehlerhaft sein etc... habe ich bis Dato noch nie erlebt.
Beschäftige dich also vorher mal mit File-Systems, zB bei btrfs -> Snapshots und Sub-Volumes, um in Zuzkunft nicht so einen grauenhaften Bullshit von dir zu geben (auch unter Berücksichtigung, dass du ja nur ein so ein 'ich bin jetzt auf Linux umgestiegen, und nutze 'Linux-Mint'-Spezialist bist).
 
  • Gefällt mir
Reaktionen: xXDariusXx
Motorrad schrieb:
"robust", und vorher waren alle Dateisysteme nicht robust!? Oder soll dieses System jetzt robuster sein als sein Vorgänger?
NTFS, wurde über die Jahrzehnte immer weiterentwickelt, stammt aus einer Zeit in der niemand von Terabyte großen Datenträgern im Taschenformat für den täglichen massenhaften Einsatz geträumt hat.

Die Voraussetzungen haben sich völlig verändert.
 
  • Gefällt mir
Reaktionen: goldeye
Piktogramm schrieb:
Mir ist auf Anhieb kein Dateisystem bekannt, welches vorsieht Prüfsummen nach dem Schreiben sofort zu verifizieren. Das würde bei HDDs und SSDs einfach viel zu sehr auf die Leistung gehen. Üblich sind eher regelmäßiges Scrubbing.
Allenfalls bei Anwendungen, bei denen die Datenintegrität wirklich wichtig ist, aber da sieht man es dann auf Anwendungsebene vor entsprechende Verifikation zu betreiben.
Für mich hört sich so an, als ob das ReFS Integrity Streams Feature genau das machen sollte.
Was du meinst ist der Integrity Scrubber, der zusätzlich immer aktiv ist und im Nachhinein beim Lesen noch einmal prüft.


Though integrity streams provides greater data integrity for the system, it also incurs a performance cost. There are a couple different reasons for this:

  • If integrity streams are enabled, all write operations become allocate-on-write operations. Though this avoids any read-modify-write bottlenecks since ReFS doesn't need to read or modify any existing data, file data frequently becomes fragmented, which delays reads.
  • Depending on the workload and underlying storage of the system, the computational cost of computing and validating the checksum can cause IO latency to increase.
Because integrity streams carries a performance cost, we recommend leaving integrity streams disabled on performance sensitive systems.
 
klausk1978 schrieb:
[...]
Beschäftige dich also vorher mal mit File-Systems, zB bei btrfs -> Snapshots und Sub-Volumes, [...]
Jeder, der im Forum einen Satz mit diesen Worten anfängt, disqualifiziert sich IMHO selbst. Du hast also die Weisheit mit Löffeln gefressen und bei dir in deiner kleinen Bubble gibts keine Probleme mit btrfs, während - so sehr ich selbst irgendwie sogar Fan von btrfs sein könnte - in einer öffentlichen Web-Diskussion an sich erstmal Jim Salters Analyse die Grundlage bleibt. Grundlage heißt nicht, dass das der heilige Gral der unbedingten Wahrheit sei, sondern, dass das die Kenntnis ist, die ich eventuell voraussetzen darf und, wenn ich das nicht tue, verlinke. Du weißt es besser als Jim Salter, dann erkläre das ausführlich oder lass es sein, aber wenn du es sein lässt, stell nicht andere als dumm hin, die sich ungefähr an Jim Salters Analysestand orientieren.
 
  • Gefällt mir
Reaktionen: aragorn92
Egal wo jemand arbeitet, keiner kann alles abschätzen, außer vllt. die Entwickler selbst und nicht mal die.
Und nur weil Funktionen vorhanden sind die teilweise sogar funktionieren können muss es nicht automatisch dauerhaft zuverlässig sein.
Wie oft haben denn gewisse Distris mal XFS oder BTRFS als Standard gesetzt und beim nächsten mal wars doch nur wieder EXT4.
Warum weiss keiner. Entweder kamen sie drauf dass noch Fehler zu beheben sind oder es gab andere Gründe.
Aber immer dieses ich brauch den geilsten letzten Scheiß jetzt und sofort bringt halt auch nix.
 
@klausk1978:

Du bringst da was durcheinander: Von Berechtigungen hatte ich nie etwas geschrieben und meine Meinung basiert, wie geschildert, auf reproduzierbaren praktischen Erfahrungen, die ich in den letzten 7 Jahren mit mehreren Distributionen gemacht habe. Außerdem nutze ich kein LinuxMint.
 
  • Gefällt mir
Reaktionen: aragorn92
Renegade334 schrieb:
Für mich hört sich so an, als ob das ReFS Integrity Streams Feature genau das machen sollte.
Was du meinst ist der Integrity Scrubber, der zusätzlich immer aktiv ist und im Nachhinein beim Lesen noch einmal prüft.


Though integrity streams provides greater data integrity for the system, it also incurs a performance cost. There are a couple different reasons for this:

  • If integrity streams are enabled, all write operations become allocate-on-write operations. Though this avoids any read-modify-write bottlenecks since ReFS doesn't need to read or modify any existing data, file data frequently becomes fragmented, which delays reads.
  • Depending on the workload and underlying storage of the system, the computational cost of computing and validating the checksum can cause IO latency to increase.
Because integrity streams carries a performance cost, we recommend leaving integrity streams disabled on performance sensitive systems.
Da steht nichts von validierendem Lesen geschriebener Daten, sondern nur zu unterschiedlichen Strategien beim Schreiben. Wobei ohne integrity etreams read-modify-write zum Einsatz kommt. Was explizit kein write-read-validate ist. Auch mit integrity streams gibt es das nicht, es erlaubt jedoch das read-modify wegzulassen und direkt auf (ungenutzte) Blöcke zu schreiben. Wobei auch ganz klar gesagt wird, dass da die Daten fragmentieren.
Und der zweite Punkt ist schlicht jener, dass Berechnen und Validieren von Checksummen Zeit kostet (Thanks Captain Obvious) und das beim Lesen wie auch Schreiben. Also keinerlei Andeuten davon, dass da nach dem Schreiben unmittelbar gelesen und validiert wird.

Wie gesagt, direkt nach dem Schreiben eines Blocks sofort wieder zu Lesen und zu Validieren ist für die meisten Anwendungsfälle ein viel zu großer Leistungsverlust[1]. Da wäre es schlauer alle Nutzdaten zu schreiben und danach einen Scrubbing über die gewünschen Blöcke laufen zu lassen.

[1]Selbst bei flotten SSDs geht der Durchsatz richtig in den Keller wenn man mixed I/O haben will. Der Durchsatz R/W verliert da je überproportional mehr als die zu erwartenden 50%.
 
Au, das gibt wieder Ärger die ersten drei Jahre.

Als ich gesehen hab, wie man aus FAT16 das FAT32 gemacht hat, hab ich mir nur die Augen gerieben.
 
Caramon2 schrieb:
[...] auf reproduzierbaren praktischen Erfahrungen, die ich in den letzten 7 Jahren mit mehreren Distributionen gemacht habe. [...]
Wenn du reproduzierbare Testfälle hast, hast du das irgendwo dokumentiert? Am Besten als Bug für den Kernel? Gerade bei Btrfs ist seit Monaten verstärkte Aktivität, da gibt es also tendenziell Interesse.
 
2014 habe ich für eine praxis einen server eingerichtet mit windows server 2012 und bemerkte neben ntfs den eintrag ReFS.

weil mir das nichts sagte und ich nur durch fehlern lerne, nutzte ich es für eine partition, die dicom bilder speichert. ich kann nicht sagen, dass es vorteile gab im vergleich zu ntfs. ganz im gegenteil!

partitionieren unter linux ist unmöglich. ich glaube, dass hat microsoft so vorgesehen: serverwelt linuxfrei machen bzw. linux keine rechte geben, auf die selbst erstellten und aufbewahrten daten zugreifen zu dürfen.

das war bei ntfs auch schon so.
Ergänzung ()

meiner ganz bescheidenen antwort nach sind btrfs und vorallem ext4 die besten dateisysteme. zfs/xfs auch. exfat ist auch gut
 
DFFVB schrieb:
ZFS ist streng genommen auch proprietär - war ja auch ein Grund warum ixsystems damals auf BSD gesetzt hat...
Wären Sie so nett das kurz zu erläutern, oder würde das den Rahmen sprengen.
 
  • Gefällt mir
Reaktionen: tollertyp
lynx007 schrieb:
Wären Sie so nett das kurz zu erläutern, oder würde das den Rahmen sprengen.
.
Also wen ich mir das so durchlese:
.
.
Microsoft betrachtet die Merkmale der Dateisysteme NTFS und ReFS und deren Erprobungsstrategie als Wettbewerbsmerkmal und legt diese nicht offen.[4]


  • Eine vollständige Spezifikation des Dateisystems ist bisher nicht öffentlich zugänglich.
  • Es gibt kein Modell mit einer Metrik für Vergleiche von Leistung und Sicherheit.
  • Eine vergleichende Bewertung des Dateisystems hinsichtlich Sicherheit und Datendurchsatz ist nicht bekannt.[5]
  • Ein Bezug zu den Redundanzverfahren RAID ist nicht bekannt.[6][7]
.
https://de.wikipedia.org/wiki/ReFS
.
Diese Punkte machen dieses Dateisystem für mich relativ uninterresant, solange es "bessere" oder "gleich" gute Lösungen gibt, die eben nicht propitär angeboten werden.
 
Ehrlich gesagt ist mir nicht klar, was mit
Ein Bezug zu den Redundanzverfahren RAID ist nicht bekannt.
gemeint ist, und sieh es mir bitte nach, aber ich werde jetzt nicht beide Quellen lesen um zu versuchen zu verstehen, was vielleicht gemeint ist.
 
Zurück
Oben