Bazzite + W11 teilen sich SteamLibrary Frage

[gea]

Ich werfe mal eine weitere Idee in den raum. Ich würde es an deiner stelle vermutlich über iSCSI oder NVMe über TCP und einem NAS realisieren, da ja wie in deinem fall immer nur eins der gebooteten Systeme exklusiven zugriff auf den Storage hat. Die I/O Leistung ist mit diesen Protokollen und einer guten Anbindung 1Gbit/s oder mehr insbesondere, was Games angeht vergleichbar mit lokalen SSDs.

Ändert ja nichts am Problem.
Ob jetzt eine Partition, eine USB Platte oder ein iSCSI target, Das sind alles blockdevices die man mit einem Dateisystem formatieren muss.

Eine OS unabhängige Option wäre SMB sofern das unterstützt wird.

 

[andy_m4]

haut gescheite (glaube sogar freie??) Treiber auf anderen Plattformen

Microsoft hat zwar die Spezifikation zu exFAT freigegeben und auch alle Patente an die Mitglieder des Open Invetion Network gewährt, aber hat meines Wissens nach keinen eigenen Open-Source-Treiber dazu veröffentlicht.

Der exFAT-Treiber im Linux-Kernel ist, stammt im wesentlichen von Samsung. Siehe dazu auch:
https://lwn.net/Articles/816934/ :

As expected, there is a new implementation of the exFAT filesystem; this one is provided by Samsung with Microsoft's blessing.

Außerdem gibts noch einen FUSE-Treiber:
https://github.com/relan/exfat

Ein Absturz beim Schreiben und fat ist häufig korrupt. Es gibt auch keine sichere Methode, Probleme zu erkennen und gar keine um diese sicher zu reparieren.

Dafür ist FAT aber simpel. Wenns kaputt geht, hat man noch eine realistische Chance was zu retten.

ZFS ist i.d.R. robuster aber auch komplexer. Wenn dort mal was kaputt geht, dann ist schnell mal der Pool weg. Und zdb hilft da auch nicht immer weiter.

Das soll jetzt nicht zwingend ein Fürsprech für FAT sein. Aber so ein bisschen differenziert sollte man das schon betrachten.

Mal davon: Über so einen non-clean Status freut sich kein Dateisystem so wirklich (ein Backup sollte man natürlich so oder so haben).
Wenn man mit Stromausfälle, häufigen Systemabstürzen oder Sonstiges in der Richtung zu kämpfen hat, dann sollte man DAS fixen. Und nicht überlegen: "Och egal. Ich nehm' ein robusteres Dateisystem" :-)

unter Windows ist der Dateisystemtreiber ein fast fertiger Release Kandidat.

Als Ergänzung:
https://github.com/openzfsonwindows/openzfs/releases

OpenZFS unter Windows bietet daher neben Laufwerksbuchstaben einen ntfs mimic Mode, bei dem ZFS vorgeben kann, ntfs zu sein.

siehe dazu auch:
https://github.com/openzfsonwindows/openzfs/wiki

Wobei man mit solchen Dingen ja auch gerade dieses plattformübergreifende auch ein stückweit verliert.
Also entweder Du trimmst das Dataset auf Windows, dann hast Du potentielle Stolpersteine unter Linux und Co.
Oder Du trimmst es auf den UNIX-Style und dann kannst Du Dir unter Windows Probleme einfangen.

Mal davon abgesehen das diese Konfigurierbarkeit ansich schon ein Problemquell sein kann.
Oder ums mal anders herum zu sagen: FAT mag sich unter Linux beschissen verhalten aber es verhält sich wenigsten immer gleich (ja; gibt noch ein paar Mount-Optionen an den man drehen kann, ist aber alles deutlich weniger umfangreich als die Möglichkeiten die ZFS bietet).

Das sollte man zumindest im Hinterkopf behalten, wenn man OpenZFS als Austauschdateisystem benutzen will.

 

[nutrix]

Die englische Mehrzahl von "library" ist
"libraries".

Wobei nur im Englischen so gültig ist, im Deutschen darfst Du so machen, z.B. Baby, Babys, Party, Partys.

 

[Uridium]

Dafür ist FAT aber simpel. Wenns kaputt geht, hat man noch eine realistische Chance was zu retten.

Einem "Journaling Dateisystem" würde ich das dennoch nicht vorziehen wollen. Vielleicht wird ja NTFSplus der Burner.

FAT Dateisysteme erinnern mich immer an Win98. Das musste man aus rein chronologischen Gründen ständig neu installieren. Da war alles instabil und unerklärlich.
youtube.com/watch?v=IW7Rqwwth84

 

[andy_m4]

Einem "Journaling Dateisystem" würde ich das dennoch nicht vorziehen wollen.

Journaling hilft nicht perse gegen Datenverlust. Es sorgt nur dafür, das Dein Dateisystem in einem konsistenten Zustand verbleibt.

Wie bereits gesagt: Wenns durch "Dinge" dazu kommt, das Du das Journal brauchst. Stell möglichst diese Dinge ab. Egal ob Du Journal hast oder nicht.

PS: Unkommentierte Youtube-Links klicke ich nicht an.

 

[Backfisch]

Wobei nur im Englischen so gültig ist

Der Threadstarter nutzt weder die (tolerable) deutsche Variante, noch die englische Version, sondern ein Apostroph. AAARGH, Leute, lernt mal, was das Ding da bedeutet.

 

[andy_m4]

Leute, lernt mal, was das Ding da bedeutet.

Fast so schlimm wie Leute, die inhaltlich nichts beizutragen haben und sich aber wegen Rechtsschreibung/Grammatik bemüßigt fühlen ein Posting zu verfassen. ;-)

 

[Backfisch]

Frei nach Wittgenstein: Die Grenzen meiner Sprache sind die Grenzen meiner kognitiven Fähigkeiten. Daher versuche ich überall dort, wo ich aktiv bin, das sprachliche Niveau meiner Mitmenschen zu heben.

 

[gea]

Einem "Journaling Dateisystem" würde ich das dennoch nicht vorziehen wollen. Vielleicht wird ja NTFSplus der Burner.

FAT Dateisysteme erinnern mich immer an Win98. Das musste man aus rein chronologischen Gründen ständig neu installieren. Da war alles instabil und unerklärlich.
youtube.com/watch?v=IW7Rqwwth84

Im Prinzip ist es Wahrscheinlichkeit.

Wenn man bei einem FAT* Dateisystem beim Schreiben den Stecker zieht, ist das Dateisystem mit hoher Wahrscheinlichkeit kaputt.

Wenn man bei ntfs oder journaling Dateisystemen den Stecker zieht, hat man ganz gute Chancen, dass zumindest nach einem chkdsk oder fschk das Dateisystem valide ist. Einzelne Dateien können defekt sein da atomare Schreibvorgänge nicht garantiert sind (schreibe Daten + Metadaten oder ein Raid Stripe sequentiell über mehrere Platten)

Wenn man bei einem Copy on Write Dateisystem wie btrfs, ReFS oder ZFS den Stecker zieht, so ist es extrem unwahrscheinlich dass man ein defektes Dateisystem oder eine defekte Datei hat, da atomare Schreibvorgänge entweder komplett ausgeführt werden oder verworfen werden.

Wenn etwas passiert, gibt es Datenrettungsprogramme, die versuchen etwas zu retten. Häufig können sie aus dem Daten Rührei aber keine Eier wiederherstellen da mangels Prüfsummen nicht feststellbar ist ob ein Datenblock noch valide ist oder nicht. ZFS versucht per Design (Copy on Write, Prüfsummen) im Vorfeld zu verhindern dass überhaupt Datenkorruption entstehen kann. Alle Daten werden grundsätzlich validiert so dass Korruption sicher festgestellt werden kann und bei beim Lesen mit Redundanz automatisch repariert wird. Zur Not gibts dann aber auch bei ZFS Datenrettungsprogramme wie klennet zfs recovery.

Es gibt übrigens kein spezielles ZFS für Windows. Es ist da aber so dass manche Programme die Dateisytemvariante abfragen und ntfs, ReFS oder fat erwarten. Kommt da als Antwort zfs, so gibts Probleme. ZFS unter Windows beantwortet so eine Abfrage nun mit ntfs. Das kann man aber per ZFS Property ändern. Ist einfach ein Workaround bis es sich herumspricht dass Windows ZFS kann.

 

[Siebenschläfer]

Das kann man aber per ZFS Property ändern. Ist einfach ein Workaround bis es sich herumspricht dass Windows ZFS kann.

Windows kann kein ZFS. Es gibt Drittanbieter-Software auf github dafür, die offenbar im Alpha-Zustand ist.

Alpha-Software ist jetzt nicht das, was man nimmt, wenn man wegen Angst vor Datenverlusten einen Bogen um Exfat macht.

 

[gea]

Es gibt auf github ZFSin. Das ist alpha und war ein proof of concept ob ZFS unter Windows lauffähig ist. Das ist aber nicht das aktuelle OpenZFS on Windows. Das ist ein release candidate.

Download: https://github.com/openzfsonwindows/openzfs/releases
Issues: https://github.com/openzfsonwindows/openzfs/issues

 

[Siebenschläfer]

Das kann der Entwickler gern "Release Candidate" nennen. Es ist trotzdem Alpha-Software, die ich auf kein Windows und keinen Zpool loslassen würde.

 

[gea]

OpenZFS on Windows ist ein Dateisystemtreiber für ein normales OpenZFS mit folgenden Issues
https://github.com/openzfs/zfs/issues und kein eigenes Dateisystem.

Der Windows Treiber kümmert sich um Windows spezifische Anpassungen wie Mountpounts, Volumes, Partitionen und Kompatibilitätsprobleme mit Windows Programmen und anderen Treibern.

Ich verfolge die Entwicklung intensiv seit 2 Jahren seit ich meine napp-it cs ZFS Storage web-gui von Solaris nach Windows portiert habe. Seit einem halben Jahr ist es wirklich brauchbar und die früheren Probleme mit Pool Import aus Linux und Probleme mit anderen Windows Programmen sind überschaubar. Von einem Datenverlust durch einen defekten Pool wegen der Windows Version habe ich seither nichts gehört.

Man kann es gerne selber testen und vor allem Issues melden. Das Hauptproblem unter Windows ist ja gerade die Vielfalt an Hardware und Programmen. Die aktuellen Issues sind überschaubar und oft unerheblich. Die Entwicklung geht eh sehr schnell. Aktuell gibt es einen neuen Release Candidate alle paar Wochen der die bekannt gewordenen Probleme beseitigt. Unter OSX hat OpenZFS bereits ein release state erreicht, unter Windows ist das nicht mehr fern.

Insgesamt sehe ich ZFS auf Windows als deutlich stabiler an als ein fat Dateisystem das ich als unsicher per design ansehe. So stabil wie nativ ZFS unter Solaris oder OpenZFS unter Illumos (Solaris fork, z.B. OmniOS) wirds natürlich nicht werden. Auch das modernere Windows ReFS das wie ZFS auch Copy on Write und Prüfsummen kann, ist noch nicht ganz problemfrei. 100% Sicherheit gibts nicht, deswegen macht man ja 321 Backup.

 

[andy_m4]

Wenn man bei ntfs oder journaling Dateisystemen den Stecker zieht, hat man ganz gute Chancen, dass zumindest nach einem chkdsk oder fschk das Dateisystem valide ist.

Ja. Weil es genau der Sinn bei Journaling ist: Konsistenz zu bewahren.
btw. auch NTFS hat Journaling.

(Copy on Write, Prüfsummen) im Vorfeld zu verhindern dass überhaupt Datenkorruption entstehen kann.

Die Blockprüfsumme ist dafür da, das man später überprüfen kann, das in dem Block die Daten korrekt drin stehen. Die verhindert nix im Vorfeld. Das ist also nicht etwa bei CRC bei der man aus (ein bisschen) kaputten Daten und der Prüfsumme die Daten rekonstruieren kann oder so.

dass man ein defektes Dateisystem oder eine defekte Datei hat, da atomare Schreibvorgänge entweder komplett ausgeführt werden oder verworfen werden.

Naja. Manchmal ist eine halbe Datei zu haben immer noch besser als sie gar nicht zu haben. Wenn die dann einfach verworfen wird, dann ist das ein Problem.
Solche Dinge lassen sich in FAT deutlich einfacher machen als bei ZFS.

Außerdem hat ZFS auch immer mal wieder Bugs die zu Datenverlust führen können.

klennet zfs recovery.

Laut https://www.klennet.com/zfs-recovery/ discontinued.
Und so far tested with und dann irgendwelche ZFS-Versionen von annodazumal. Sehr hübsch :-)

Klar. Im Notfall besser als nix.

Es ist trotzdem Alpha-Software,

Woran machst Du das fest? An der Menge der offenen Issues? Falls ja, dürfte man ZFS auch unter Linux nicht einsetzen: https://github.com/openzfs/zfs/issues :-)

Ergänzung (Gestern um 12:30)

fat Dateisystem das ich als unsicher per design ansehe

Wenn man nicht gerade Abstürze oder Stromunterbrechungen oder Trennung ohne umount hat, sollte FAT keine Probleme machen.
FAT hat halt den Vorteil das es ausgereift ist und (anders als bei ZFS) auch keine Features mehr hinzukommen (es werden also auch nicht pootentiell neue Bugs eingeschleppt).

Das soll jetzt keine Empfehlung für FAT sein.

Aber dieses einseitige und undifferenzierte "bei FAT ist ALLES doof und bei ZFS ist ALLES toll" klingt ziemlich fanboy-mäßig und entwertet damit auch ein stückweit deine richtigen Aussagen.

 

[gea]

Man muss das genauer betrachten

Ja. Weil es genau der Sinn bei Journaling ist: Konsistenz zu bewahren.
btw. auch NTFS hat Journaling.

Das Problem sind abhängige atomare Schreibvorgänge die niemals nur teilweise ausgeführt werden dürfen. Journaling schützt keine atomaren Schreibvorgänge sondern verringert nur das Zeitfenster in dem Probleme beim Schreiben auftreten können. Lediglich in Kombination mit einem Hardware Raid Adapter mit Cache Absicherung z.B. per BBU kommt ein Journaling Dateisystem nahe an das heran was Copy on Write leistet.

Die Blockprüfsumme ist dafür da, das man später überprüfen kann, das in dem Block die Daten korrekt drin stehen. Die verhindert nix im Vorfeld. Das ist also nicht etwa bei CRC bei der man aus (ein bisschen) kaputten Daten und der Prüfsumme die Daten rekonstruieren kann oder so.

Prüfsummen melden defekte Dateien und reparieren beim Lesen automatisch falls es Redundanz gibt. Metadaten sind bei ZFS immer redundant

Naja. Manchmal ist eine halbe Datei zu haben immer noch besser als sie gar nicht zu haben. Wenn die dann einfach verworfen wird, dann ist das ein Problem.

Copy on Write verwirft keine Dateien sondern belässt sie bei einem Absturz auf dem letzten validen Stand.

Solche Dinge lassen sich in FAT deutlich einfacher machen als bei ZFS.

Außerdem hat ZFS auch immer mal wieder Bugs die zu Datenverlust führen können.

Jede Software hat bugs, egal welche, daher Backup.
Das kann gerne auf einem anderen OS, Dateisystem oder Dateisystem Release sein.

Laut https://www.klennet.com/zfs-recovery/ discontinued.
Und so far tested with und dann irgendwelche ZFS-Versionen von annodazumal. Sehr hübsch :-)

Klenet ZFS Recovery has been discontinued. ZFS recovery features have been integrated into Klennet Recovery proper. ZFS recovery ist also jetzt im ganz normalen Klennet enthalten und kein eigenständiges Produkt mehr.

Klar. Im Notfall besser als nix.

Recovery ist immer nur "besser als nix". Besser ist Vorsorge zu treffen, dass man Notfall Recovery nicht braucht und dafür wurde ZFS bei Sun entwickelt.

Woran machst Du das fest? An der Menge der offenen Issues? Falls ja, dürfte man ZFS auch unter Linux nicht einsetzen: https://github.com/openzfs/zfs/issues :-)

in der Tat

 

[Uridium]

An ZFS hat mich immer gestört, dass es nur out-of-tree in den Kernel darf. Darum hatte ich mich für bcachefs mit checksumming (für Backups und Bitrot) entschieden. Dass das zum Schenkelklopfer geworden ist, ist bedauerlich. Ich werde aber vermutlich dennoch dabei bleiben. Ist ja jetzt gehopst wie gesprungen.

Als Inter-OS Dateisystem würde ich NTFS nehmen. Der "Mischbetrieb" wird eh nicht allzu lange anhalten. Nach meiner Erfahrung entscheidet man sich recht schnell für ein "Schwerpunkt-OS" und das andere verkümmert.

 

[andy_m4]

Das Problem sind abhängige atomare Schreibvorgänge die niemals nur teilweise ausgeführt werden dürfen.

Daher gibts bei NTFS auch sowas wie Transaktionen.
btw.: Mir ist der Unterschied klar und den hast Du ja auch gut heraus gestellt.
Aber dein Argument war halt, das "chkdsk" schnell durchläuft. Darauf bezog sich das.
Und mein zweiter Punkt war, das Du suggeriert hast, das NTFS kein Journaling hat was so halt in der Pauschalität nicht stimmt.

Prüfsummen melden defekte Dateien und reparieren beim Lesen automatisch falls es Redundanz gibt.

Ja eben. Falls es Redundanz gibt. Aber das ändert ja nichts dran, das Prüfsummen nur der Detektierung von Fehlern dient.
Es war sicherlich nur missverständlich von Dir ausgedrückt.

Copy on Write verwirft keine Dateien sondern belässt sie bei einem Absturz auf dem letzten validen Stand.

Ja eben. Die neuen Daten sind nur schwer zugänglich.
Die wurden halt verworfen. Das ist im Sinne der Konsistenz natürlich gut und richtig. Das ist aber genau dann doof, wenn ich die neuen Daten haben will und damit leben kann, das sie korrupt oder unvollständig sind.

Jede Software hat bugs, egal welche, daher Backup.

Ja. Lustig ist, das Du das für ZFS so sagst. Aber wenn bei FAT Fehler auftreten, dann ist das schlimm und das Backup-Argument kommt nicht.
Ist halt einfach nicht konsequent.

ZFS recovery ist also jetzt im ganz normalen Klennet enthalten und kein eigenständiges Produkt mehr.

Wenn man Sachen einfach verlinkt, hat man solche Missverständnisproblem mehr.

Darum hatte ich mich für bcachefs mit checksumming (für Backups und Bitrot) entschieden.

Ja. bcachefs sieht ja eigentlich auch von den Ansätzen gut aus.
Ein modernes Dateisystem was auch das learning aus ZFS mit berücksichtigt.

An ZFS hat mich immer gestört, dass es nur out-of-tree in den Kernel darf.

Ja. Ist nicht schön.

Auf der anderen Seite:
Wer sich für ZFS entscheidet hat ja oftmals auch gewichtige Gründe dafür. Und dann fällt das nicht mehr ganz so ins Gewicht. Dann nimmt man halt eine Distribution welches das gut supportet und dann hat man i.d.R. ja auch kein Problem.

Und bei bcachefs ist es ja sogar noch ein Tick problemloser.

 

[gea]

Copy on Write vs Journaling bei Absturz beim Schreiben

Journaling ist schonmal sehr gut. Es schützt aber vor allem die Metadaten und Datenstrukturen.
Copy on Write mit Prüfsummen geht einen Schritt weiter. Es schützt auch Dateien mit Stand vor dem Absturz sowie Raid Stripes was Journaling gar nicht abdeckt. Da kann alles gut ausehen, selbst wenn bei einem Mirror beide Hälften unterschiedliche Daten haben. Journaling war halt Stand der Technik von vor 30 Jahren, Copy on Write mit Prüfsummen ist heute Stand der Technik.

Backup:

ZFS ist mit das Sicherste für die Daten. Bis auf menschliche Fehler, fehlende Redundanz bzw Snaps oder defekte Hardware sind praktisch alle Risiken abgedeckt, egal ob bitrot, write hole oder Abstürze beim Schreiben. Es wäre aber fahrlässig, kein Backup zu haben. ZFS ist sicher aber ersetzt kein Backup. Gilt für weniger sichere Dateisysteme umso mehr.