/c/ – Pufferüberlauf

Felix sollte schon wissen was er tut, wenn er Butterfs verwenden will.

Solange man genügend Speicher frei hat, ist es in Felixens Erfahrung stabil. Felix hat eine fast volle Platte. Da dachte Felix sich, er erweitert den Speicher um eine weitere Platte. Dazu muss man die erste Platte ausbalancieren. Das ging schief, weil eben nicht genügend Speicher frei war. Es ging nichts mehr, auch löschen half nicht und irgendwann war das Ding nicht mehr verwendbar.
Später lernte Felix von der Option -o degraded. Damit konnte er das Dateisystem immerhin nur lesbar einhängen. Da es sowieso nur ein Datengrab ist, stört es ihm nicht weiter. Felix verwendet es nun in Kombination mit Überlagerungsdateisystem.

Abgesehen davon verwendet Felix Butterfs inzwischen auch für seine Betriebsysteme mit Schnappschüssen. Rückrouladen hat er bislang noch nicht gebraucht, aber er hat schon mal ein paar Dateien aus Schnappschüssen wiederhergestellt.

>>159920
Ähnliche Erfahrungen hat Felix mit ZFS auch schon gemacht. Mache vor allem niemals den Fehler, Deduplizierung zu aktivieren. Du kannst es nicht rückgängig machen und dein Dateisystem ist danach effektiv schrott, nicht mehr zugreifbar, da hilft nur noch komplett mit dd wipen.

>Btrfs
Das darf man nur niemals nicht nie mit RAID/mdadm verwenden, weil extrem karpott. Die Btrfs-Leute machten auch in den letzten 10 Jahren keine Anstalten, das zu fixieren.

https://www.phoronix.com/news/Btrfs-Warning-RAID5-RAID6
https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices

>ZFS
Das Mem schlechthin, wenn man seine eigenen Computerey-Spielereien als "Homelab" bezeichnen muss und ECC-Speicher aus FUD-Gründen verbauen will.
ZFS hat manchmal nicht nachvollziehbare Beschränkungen. Z.B. wäre die Erweiterbarkeit von vdevs, insbesondere für Heimnutzer, extrem praktisch. Gibt es nicht. Felix hat nie einen plausiblen Grund gehört, warum so eine Kernfunktionalität einfach fehlt.

>ext4
Das gute, alte, bewährte. Abgehangen und mit einem e2fsck-Tool, das einem im Fall der Fälle den Arsch rettet. Dabei deckt e2fsck mehr Fälle ab als entsprechende Tools bei anderen Dateisystemen, siehe PDFs relatiert.

>F2FS
Das hippe, neue Dateisystem für SSDs, insbesondere für NVMe. Weil es seit einigen Jahren das Standard-Dateisystem für Android ist, gibt es so langsam genug Benutzer, dass es irgendwann die Chance hat, das "gute, neue, bewährte" Dateisystem zu werden.

F2FS hat greifbare Vorteile für den Heimbenutzer mit Desktop-PC. Erst mal: Für Felix sind die ganzen Servierer-Bankmarken von Phoronix für SQLite, PostgreSQL, MariaDB, CockroachDB RocksDB vollkommen wurscht. Felix betreibt bei sich zu Hause keinen Datenbank-Servierer mit fettem DBMS, das geht komplett an Felixens Nutzfall vorbei. Felix will stattdessen, dass sein System noch ein Terminal-Fenster in weniger als 5 Sekunden öffnen kann, während im Hintergrund beispielsweise ein Haufen Dateien kopiert werden oder zu einer .zip-Datei komprimiert werden. Und ja, genau das ist leider bei einigen Dateisystemen ein Problem.

Genau da hat F2FS die Nase vorn. Phoronix hat bis vor ein paar Jahren noch den "Application Start-up Time"-Bankmarke durchgeführt, seit ein paar Jahren (warum auch immer) leider nicht mehr. Die Bankmarke testet, wie lange es dauert, eine bestimmte Anwendung (xterm, GNOME Terminal, LibreOffice Writer) zu öffnen, während im Hintergrund Lese-, Schreib- oder Schreib-/Lese-Zugriffe stattfinden. Also genau das, was für Felix am Desktop-PC relevant ist.

In der "Application Start-up Time"-Bankmarke hat dabei F2FS die anderen Dateisysteme hinter sich gelassen, insbesondere ist F2FS dabei deutlich schneller als ext4 oder Btrfs:
https://www.phoronix.com/review/linux-58-filesystems/2
https://www.phoronix.com/review/linux-50-filesystems/4

Siehe auch Bild relatiert: Auf ext4 braucht das Öffnen vom GNOME-Terminal bei Hintergrundlast schon mal 5 Sekunden.

Felix sagt aber auch gleich, wo das aktuelle Problem liegt:
>F2FS has a weak fsck that can lead to data loss in case of a sudden power loss [3][4].
>If power losses are frequent, consider an alternative file system.
Ext4 hat aktuell ein deutlich mächtigeres e2fsck als das fsck von F2FS. Siehe dazu auch Seite 7 und 8 von PDF 1 relatiert.

Felix setzt F2FS seit Jahren in seinen VMs ein, und das sind häufig Blutige-Kante-VMs mit Gentoo, die auch schon mal (wegen Felixens Spielereien) unsanft hängen bleiben und von Felix dann unmittelbar terminiert werden. Trotzdem hatte Felix zumindest in seinen VMs bei der Nutzung von F2FS noch nie Datenverlust oder sonstige Probleme mit dem Dateisystem von F2FS.

F2FS hat Felixens Meinung nach wirklich das Zeug zum Nachfolger von ext4 in ~10 Jahren, eben weil es durch Android so viele Nutzer als Meerschweinchen zum Testen bekommen hat. Es muss aber mindestens noch beim fsck und präventiven Vorsichtsmaßnahmen im Falle vom plötzlichen Stromausfall nachgebuttert werden.

>Wie handhabt Felix Rückaufs? Mit ZFS/Btrfs Schnappschüssen? Auf Blockebene mit LVM? Oder altschul mit rsync?
Altmodisch via rsync, bei komplexeren Szenarien FreeFileSync (freie und offene Soße). Felix kann letzteres nur empfehlen.
Denn Felix vertraut keinen Rückaufs, welches nicht durch Luftbrücke getrennt ist. Er hatte da mal einen Zwischenfall mit dem Netzteil in einem Arbeits-PC.

>>159924
>ZFS hat manchmal nicht nachvollziehbare Beschränkungen. Z.B. wäre die Erweiterbarkeit von vdevs, insbesondere für Heimnutzer, extrem praktisch. Gibt es nicht. Felix hat nie einen plausiblen Grund gehört, warum so eine Kernfunktionalität einfach fehlt.
Vielleicht hast du da einfach etwas missverstanden. Bei ZFS gibt es recht viele Konzepte und die sind manchmal verwirrend. Du kannst ein vdev zwar nicht erweitern, du kannst aber ein neues vdev zu einem Pool hinzufügen. Der Pool ist das entscheidende, das ist das, was du letztendlich benutzt. Vdevs sind lower-level, gewissermaßen ein Implementierungsdetail. Du kannst also sehr wohl dein ZFS um weitere Platten erweitern.

Felix versucht es mal mit einer Analogie: Ein Pool verhält sich zu einem vdev wie ein JBOD zu einer einzelnen Festplatte. Bloß dass das vdev intern noch mal aus mehreren Festplatten besteht und dadurch eingebaute Parität hat.

Dass das so gelöst wurde, wird wohl technische Gründe haben. Ich finde das durchaus nachvollziehbar und keineswegs willkürlich. Wenn du einzelne vdevs erweitern können wolltest, dann müsstest du in dem Z-RAID irgendwie die Daten lebend herumschieben und neu balancieren, ohne dass etwas dabei kaputt geht. Das klingt extrem kompliziert und fehleranfällig.

Es wäre vielleicht machbar für bestimmte Arten von RAIDs, vor allem RAID-1. Aber bei sowas wie RAID-5 oder RAID-6... die Hölle. Und bei RAID-1 hat es keinen Vorteil gegenüber der bestehenden Lösung.

Nachtrag:
>atc19_slides_jaffer.pdf
Ja, das entspricht so ungefähr auch Felix' Erfahrung mit Btrfs, leider >>159822:
>Btrfs, hat Felix auch gemischte Erfahrungen mit gemacht. Solange es funktioniert, ist es toll. Hast du aber einmal irgendwo versehentlich - in Felix Fall durch Anwenderfehler - irgendwo einen Sektor mit Müll überschrieben, ist das ganze Dateisystem wek und lässt sich auch nicht mehr reparieren. Mit Ext4 wäre das nicht passiert. Sollten Dateisysteme wie ZFS und sein hässlichen Halbbruder Btrfs nicht gerade besonders resilient sein?

>Denn Felix vertraut keinen Rückaufs, welches nicht durch Luftbrücke getrennt ist
Das eigentlich kühle an ZFS/Btrfs ist ja die send/receive Funktion. Felix hatte immer die Idee, die ZFS diffs einfach auf Amazon Glacier zu parken. Stellte sich dann leider raus, dass das nicht so funktioniert hätte, wie Felix sich das gedacht hatte, weil die Verschlüsselung damals auf Block-Ebene (also unterhalb ZFS) implementiert war und die diffs unverschlüsselt gewesen wären. Hätte man natürlich lösen können, indem man sie noch mal extra verschlüsselt, aber da war Felix' Enthusiasmus irgendwie vorbei und deshalb wurde das nie umgesetzt.

Inzwischen sollte das, was Felix sich damals vorgestellt hat, dank ZFS-integrierter Verschlüsselung und "raw" sends/receives funktionieren, allerdings gibt es da jede Menge Käferberichte im Netz. Wirklich stabil scheint das noch nicht zu sein.

>>159925
>Vielleicht hast du da einfach etwas missverstanden. Bei ZFS gibt es recht viele Konzepte und die sind manchmal verwirrend.
Felix lässt sich sofort eines besseren belehren, aber Felix glaubt, dass er hierbei richtig liegt. Felix hat das Thema in den letzten Jahren allerdings nicht aktiv verfolgt. Felix hat seit dem letzten Pfosten einen (für Felix neuen) Artikel aus dem Jahre 2022 gefunden, bei dem es genau darum geht (aber noch zu kurz greift):
https://freebsdfoundation.org/blog/raid-z-expansion-feature-for-zfs/

>Wenn du einzelne vdevs erweitern können wolltest, dann müsstest du in dem Z-RAID irgendwie die Daten lebend herumschieben und neu balancieren, ohne dass etwas dabei kaputt geht.
Genau das erwartet Felix von einem Dateisystem, das unbedingt RAID selbst integrieren musste. Das wird im Artikel als "reflow" bezeichnet. Das korrekte Endergebnis wäre dann so, als ob die Platte schon von Anfang an dabei war, nicht zuletzt aus Performanz-Gründen (man denke daran, von welchen Platten für alte vs. neue Dateien gelesen wird). Abstraktionen vom "Implementierungsdetail" funktionieren nicht, wenn die Realität (Performanz) durch die Abstraktionslücken hindurchblubbert.

Wie man an Bild relatiert aber sieht:
Die Daten wurden weiterhin nur in 4er Stripes geschrieben. Man hat also weiterhin für diese Daten nur die Effizienz von 3 Daten + 1 Parität (75 %), statt 4 Daten + 1 Parität (80 %).

Die Nutzermeinungen sind dementsprechend noch nicht so überzeugend:
https://old.reddit.com/r/truenas/comments/1k904xd/is_raidz_vdev_expansion_now_possible/mpdak9y/
https://old.reddit.com/r/homelab/comments/1i1746f/raidz_expansion_is_officially_released/m73s5p2/

Felix weiß noch, dass Backblaze ihre eigene RAID-Implementierung geschrieben hat, mit generischen n-k-Reed-Solomon-Codes als Paritätsdaten. Da muss man dann nicht mehr sich mit RAID1/5/6/z1/z2/z3 rumschlagen, sondern kann sagen, man hat n Platten, von denen (n-k) ausfallen dürfen. Backblaze benutzte 20-17, aber wenns noch größer wird, kennt Felix keinen anderen Weg für >3 Platten Ausfallsicherheit (mehrere vdevs helfen da nicht).

>>159929
>Inzwischen sollte das, was Felix sich damals vorgestellt hat, dank ZFS-integrierter Verschlüsselung und "raw" sends/receives funktionieren, allerdings gibt es da jede Menge Käferberichte im Netz. Wirklich stabil scheint das noch nicht zu sein.
Dazu kamen Felix auch gerade Berichte in den obigen Habsgelesen-Fäden unter.

>Who knows, maybe 2.4.0 will stop encryption from shredding people's data. Anything is possible at this point.
https://github.com/openzfs/openzfs-docs/issues/494
Gut zu wissen, Felix hat das nie zusammen benutzt.

>>159930
>Felix weiß noch, dass Backblaze ihre eigene RAID-Implementierung geschrieben hat, mit generischen n-k-Reed-Solomon-Codes als Paritätsdaten. Da muss man dann nicht mehr sich mit RAID1/5/6/z1/z2/z3 rumschlagen, sondern kann sagen, man hat n Platten, von denen (n-k) ausfallen dürfen. Backblaze benutzte 20-17, aber wenns noch größer wird, kennt Felix keinen anderen Weg für >3 Platten Ausfallsicherheit (mehrere vdevs helfen da nicht).
Ja, das ist natürlich schön und gut. Ich verstehe ehrlich gesagt schon lange nicht, warum man sich immer noch mit den komischen RAID-Levels rumschlängt statt einfach generischem Reed-Solomon. Aber was du forderst, wäre ja quasi ein Reed-Solomon mit nachträglich änderbaren n-k, und das ganze online, während der Betrieb weiterläuft (und ZFS ist ohnehin schon komplex genug). Da würde ich auch sagen: Leckt mich.

>>159912
>Welches Dateisystem verwendet der Felix von Welt heutzutage?
>auf Linux?
Wollte neulich mal einen mit ein paar Musik-Dateien befüllten USB-Stick vom Linux-basierten[0] Medienabspielgerät meines Pkws (Baujahr 2020) abspielen lassen. Ergebnis: FAT32 war das einzige "Dateisystem" welches verstanden wurde.

--
[0] Diese auf Endnutzergeräten am weitesten verbreitete aber unter euch Linux-Spezialexperten kaum bekannte Distro.

>>159936
Eigentlich alles richtig gemacht. Wieso Dateisysteme in den Kernel einkompilieren, die der Endnutzer sowieso nicht benutzt? Wer hat schon einen Ext3- oder Ext4-formatierten USB-Stick? Am Ende wird das Infotainmentsystem noch gehackt über diese zusätzliche Angriffsfläche!!1

>>159931
>Aber was du forderst, wäre ja quasi ein Reed-Solomon mit nachträglich änderbaren n-k, und das ganze online, während der Betrieb weiterläuft (und ZFS ist ohnehin schon komplex genug).
Naja, man muss ja nicht gleich die RAID-Stufe ändern, bloß weil man eine Platte hinzufügt. Felixens Einwand gilt bereits für eine gleichbleibende RAID-Stufe. Und die Parität in RAIDz1 ist ein ... XOR. Für den Effizienzgewinn im obigen Beispiel würde es reichen, statt 3 Daten + 1 XOR dann 4 Daten + 1 XOR zu speichern.

Volle Flexibilität auch bzgl. der RAID-Stufe wäre natürlich schöner, aber bereits ein solcher Zwischenschritt würde einiges voranbringen. Und das ganze zunächst abschnur zu machen, wäre auch oke. Der Nutzfall ist eben, dass der Heimanwender eine Festplatte hinzufügt und dann das RAID darauf verteilt wird, und man dann so dasteht, als hätte man nie zu wenig Platten gekauft. Und man kauft auf lange Sicht immer zu wenig Platten. Aber bislang (bis vor den obigen Blog-Pfosten) hatte da ZFS einfach garnichts (neues vdev hinzufügen ist nicht äquivalent), noch nicht einmal die einfachen Fälle.

Übrigens gibt es statt den Reed-Solomon-Kots von Backblaze auch noch bei bcachefs eine Implementierung basierend auf endlichen Körpern:
https://github.com/koverstreet/bcachefs-tools/blob/master/raid/raid.c#L18-L169

>>159949
>Und die Parität in RAIDz1 ist ein ... XOR. Für den Effizienzgewinn im obigen Beispiel würde es reichen, statt 3 Daten + 1 XOR dann 4 Daten + 1 XOR zu speichern.
Bei RAIDZ-1 vielleicht. Aber dafür erhöht sich auch das Riskio eines katastrophalen Schadens mit jeder Platte, die du hinzufügst. Es wäre jetzt keine gute Idee, da 100 Platten hinzuzufügen.

>>159950
Klar, und weiter? Was ist der Grund, das nicht zu implementieren?
Es hält dich auch niemand davon ab, von Anfang an einen RAIDz1-Pool mit 100 Platten zu erschaffen.

Man sollte nicht alles ablehnen, bloß weil das in einem Extrembeispiel unklug wäre. Das ist wirklich der schlechteste Grund, auf ein "NEIN, du DARFST keine Platten einem vdev hinzufügen! Es ist der ZFS-Weg!" zu bestehen.

>>159951
>Was ist der Grund, das nicht zu implementieren?
Du kannst es ja implementieren. Ich würde es auch nicht implementieren.

>>159952
Du beantwortest die Frage nicht.

Die wahrhaftige Erkenntnis ist natürlich, das alles wegzuschmeißen, weil ein Heimanwender sowieso kein RAID braucht, weil er nicht Hochverfügbarkeit braucht, sondern Backups. Da reicht es auch, via LVM alle Platten zu einem logischen Volumen zu vereinen.

>>159953
>Du beantwortest die Frage nicht.
Der Grund ist, dass das ziemlich viel Kot für einen ziemlichen (fragwürdigen) Nischenanwendungsfall ist. ZFS ist auch für Unternehmen konzipiert, da denkt keiner darüber nach, eine einzelne Platte in ein vdev einzuschieben. Wenn man den Speicher erweitern will, dann fügt man einfach neue vdevs hinzu. Wie viel RAID-Sicherheit man braucht, hat man vorher geplant.

>>159954
>ziemlich viel Kot
Vielleicht, vielleicht nicht. Müsste man die Entwickler mal fragen.

>(fragwürdigen) Nischenanwendungsfall
Die im Faden verelften Habsgelesen-Fäden sehen das anders.

>ZFS ist auch für Unternehmen konzipiert, da denkt keiner darüber nach, eine einzelne Platte in ein vdev einzuschieben.
Warum? Auch Unternehmen können nicht magisch Festplatten größerer Größe kaufen, als auf dem Markt aktuell verfügbar. Irgendwann wird der Speicher knapp und man muss Speicherplatz nachbuttern. "Unternehmen" umfasst auch die Ich-AG vom Weichwarenentwickler mit 1 Mitarbeiter (ihm selbst). Soll man jetzt auch noch vorschreiben, wie die Nutzer ihren Festplatten-Kram zu kaufen haben (nach der Erfolgsvorschrift ECC-Speicher)?

Übrigens schöner Strohmann mit dem "eine einzelne Platte einzuschieben, will doch keiner, was willst du also damit". Felix hat es explizit als einfacheren Zwischenschritt benannt, der zuerst erklommen werden könnte, und direkt einigen Nutzern Nutzen bringt. Das schließt nicht aus, dass man auf der Basis dann noch mehr implementiert, von dem dann noch mehr Nutzer profitieren. Eine gute Basis für weiteres, das will man damit. Die Maximalforderung (und zweiter Strohmann), dass man direkt n-k-Reed-Solomon, mit Änderbarkeit von n und k, und mit Anschnurfunktionalität bräuchte, und das dann ja alles so schrecklich kompliziert werden würde, kam von dir.

>Wenn man den Speicher erweitern will, dann fügt man einfach neue vdevs hinzu.
Das bringt einem bei RAID _nicht_ die gleiche Ausfallsicherheit. Ein 4+2-vdev hat mehr Ausfallsicherheit als zwei 2+1-vdevs (obwohl jeweils 6 Platten). (Ersteres hat eine kubische Ausfallwahrscheinlichkeit, letzteres eine höhere quadratische Ausfallwahrscheinlichkeit.) Deswegen ist selbst RAIDz3 für viele Platten im zpool (in vielen vdevs) zu beschränkt. Die ganze Unterteilung von mehreren vdevs in einem zpool ist stochastischer Unfug. Das ist leider ein Geburtsfehler von ZFS.

>Wie viel RAID-Sicherheit man braucht, hat man vorher geplant.
Menschliche Planung ist fehlerbehaftet, Flexibilität wäre besser. Da kann man auch sagen, wie das Dateisystem aussehen soll, hat man vorher geplant. Dateien muss man also gar nicht umbenennen können.

Felixens Kritik richtet sich übrigens nicht gegen die ZFS-Entwickler. Jeder Offene-Soße-Entwickler ist für Felix ein Held und Felix würde den Entwickler niemals ankacken. "Kühl, kostenlose, freie Weichware, wunderbar" denkt sich Felix. Bei den ZFS-Lüftern, die das In-Stein-Meißeln von vdevs zum ZFS-Weg erklärt haben, sieht es anders aus. Dass man etwas _nicht_ tun kann als tolle Sache anzusehen, darauf können nur Lüfter kommen.

>>159955
>"Unternehmen" umfasst auch die Ich-AG vom Weichwarenentwickler mit 1 Mitarbeiter (ihm selbst)
Für den ist ZFS aber nicht konzipiert. ZFS ist "Enterpreis".

Wenn du Kapazität hinzufügst, dann willst du immer auch Parität hinzufügen. Ansonsten kannst du dir dein RAID gleich sparen. Sei halt kein Geizkragen und füg drei Festplatten zu deinem Pool hinzu statt einer, zwei für Kapazität und eine für Parität.

>>159956
>ZFS IST ENTERPREIS
t. frickel-mongo, verwendet zfs on linux.

Häng dich einfach weg, du dreckiger Untermensch ich ficke deine wertlose runtergekommene Hurenmutter du Missgeburt. Ich fremdschäme mich, weil ich weiß, dass du existierst. Einfach totschlagen müsste man solche miesen kleinen behinderten Klugscheißer wie dich.

>>159957
>verwendet zfs on linux.
Tu ich ja nicht, beleidige mich doch wenigstens mit etwas, das stimmt. Bist du schon wieder auf Entzug?

>>159924
>Felix will stattdessen, dass sein System noch ein Terminal-Fenster in weniger als 5 Sekunden öffnen kann
Warum nicht preload verwenden?
https://www.computerbild.de/artikel/cb-Tipps-Software-Superfetch-fuer-Linux-Preload-bringt-Windows-Tuning-Feature-in-Ubuntu-39399747.html

>>159956
>Für den ist ZFS aber nicht konzipiert. ZFS ist "Enterpreis".
Unternehmensregister: Umfirmierung von "Felix AG" in "Felix Enterprises AG", hat auch für HP geklappt.

>PJD: We want to release ZFS for every architecture we support, but we don't recommend ZFS for 32-bit architectures.
>...
>DB: I think the assumption is pretty valid in terms of what has happened with hardware commoditization and cost. Hardware has become free and you can have large tracts of physical memory and disk and everything, but, unfortunately, people still have these old applications, relying on these old operating systems.
>JB: Sometimes it's new ones, too. It's not your next desktop; it's your next laptop, or PDA, or cellphone, and all of a sudden, you have this new class of device and you're back to square one. You have more limited addressing, a smaller amount of memory, and less compute power, and you want to be able to fit in those devices.
>DB: The "ZFS for my cellphone" kind of problem.
>BM: Actually, we've released ZFS not as a be-all, end-all product; we've tried to design and maintain it in such a way that it's really not just an endpoint but rather a starting point. It's a framework, with the transactional object store and the pooled storage, on top of which you can build far more interesting things.
https://spawn-queue.acm.org/doi/pdf/10.1145/1317394.1317400
(Achtung: Elfe geht zur Bild-Zeitung der ACM.)

Das klingt dann nicht mehr nach "nur Servierer" oder gar "nur Enterprise".

Historische Einordnung: Das Interview ist vom September/Oktober 2007. Doch dann:
>In 2007–2008, Sun posted revenue of $13.8 billion and had $2 billion in cash. First-quarter 2008 losses were $1.68 billion; revenue fell 7% to $12.99 billion. Sun's stock lost 80% of its value November 2007 to November 2008, reducing the company's market value to $3 billion.
>Acquisition of Sun Microsystems by Oracle Corporation: Initiated April 20, 2009

>Wenn du Kapazität hinzufügst, dann willst du immer auch Parität hinzufügen. Ansonsten kannst du dir dein RAID gleich sparen.
Wenn ich von 2 Daten + 1 Parität auf 3 Daten + 1 Parität gehe, und mit der Ausfallsicherheit oke bin (1 Ausfall, habe komplette Backups), warum sollte ich das nicht wollen? Und nein, das ist offensichtlich dann immer noch nicht äquivalent zu gar kein RAID. Vielleicht sollte man eher mal anfangen, den anderen Nutzern nicht irgendwelche Vorschriften zu machen, was er tun dürfe.

Das nimmt bei ZFS bzw. bei deren Lüftern so langsam Züge von Stockholm-Syndrom an:
*Nein, du darfst keinen normalen RAM kaufen! Es muss ECC-RAM sein!
*Nein, du darfst keine Platten zu einem vdev hinzufügen! Es muss ein neues vdev werden! (Resultat: Geringere Ausfallsicherheit)
*Nein, du darfst die RAID-Stufe nicht verändern! Es muss vorher mit 20/20-Vision die perfekte RAID-Stufe gewählt werden!

>Sei halt kein Geizkragen und füg drei Festplatten zu deinem Pool hinzu statt einer, zwei für Kapazität und eine für Parität.
Wird dann ein neues vdev und 2 vdevs bringen _nicht_ die gleiche Ausfallsicherheit wie 1 vdev. Das hat doch Felix gerade ausgeführt! Soll das Felix nun noch einmal im Detail für diesen Fall vorrechnen?

Hier, was der Nutzer aktuell machen müsste, um die korrekte Ausfallsicherheit zu erreichen:
*Kompletten Pool (bestehend aus 1 vdev) backuppen
*Pool zerstören und auf allen Platten jungfräuliche Partitionen formatieren
*Neuen Pool (bestehend aus 1 vdev) mit den alten und zusätzlichen Platten erstellen
*Backup zurückspielen
Ja, toll.

>>159963
>Wird dann ein neues vdev und 2 vdevs bringen _nicht_ die gleiche Ausfallsicherheit wie 1 vdev.
Das hat auch niemand behauptet. Aber das, was du willst geht nicht, ohne >>159955 >dass man direkt n-k-Reed-Solomon, mit Änderbarkeit von n und k, und mit Anschnurfunktionalität bräuchte

Außer: Eventuell könntest du bei jedem neuen vdev die Redundanz erhöhen, also von RAID-Z1 auf RAID-Z2 und irgendwann RAID-Z3 (glaube ZFS unterstützt auch sowas wie RAID-1 aber mit n Kopien... also beliebieg erhöhbar)... vielleicht könntest du dir das so hinbiegen, dass die Reihe konvergiert. Kannst ja mal rechnen, wenn du Bock hast. Aber das ist jetzt wirklich autistisch. Keine Ahnung, ob das hier aufgeht, aber ich habe sowas ähnliches mal für Bloom-Filter durchgerechnet, dann später rausgefunden, dass das schon vor mir jemand erfunden hat.

Ich kenne jedenfalls kein Dateisystem, dass deine Wunschanforderungen erfüllt. ZFS hat da eine Designentscheidung getroffen, die einen Kompromiss aus Komplexität, Geschwindigkeit, und Funktionalität darstellt. Und was besseres ist mir da in der Hinsicht bisher nicht bekannt. Vielleicht irgendwelche proprietären Lösungen wie bei Backblaze.

>>159964
Noch Ergänzung: Deine Idee, eine neue Platte zum existierenden vdev hinzuzufügen, ohne Parität hinzuzufügen, das kannst du vielleicht ein, zwei mal machen. Danach kannst du dir das RAID auch gleich sparen. Deswegen ist das für mich ein ziemlicher Nischenanwendungsfall.

>>159964
>Aber das, was du willst geht nicht, ohne >>159955 >dass man direkt n-k-Reed-Solomon, mit Änderbarkeit von n und k, und mit Anschnurfunktionalität bräuchte
Wie du geschrieben hast, für die kleinen RAID-Stufen muss man noch nicht n-k-Reed-Solomon-Kots draufhauen.
Das "anschnur" wäre auch noch optional.

>>159965
>Deine Idee, eine neue Platte zum existierenden vdev hinzuzufügen, ohne Parität hinzuzufügen, das kannst du vielleicht ein, zwei mal machen. Danach kannst du dir das RAID auch gleich sparen.
Naja, wenn man sich an die im Netz rumdümpelnden Empfehlungen zur maximalen Plattenzahl hält, gibt es zumindest:

1+1 → 2+1 → 3+1 → 4+1 → 5+1 → 6+1
2+2 → 3+2 → 4+2 → 5+2 → 6+2 → 7+2 → 8+2
3+3 → 4+3 → 5+3 → 6+3 → 7+3 → 8+3 → 9+3 → 10+3 → 11+3 → 12+3

Das sind schon eine Menge Aufrüstfälle (und das ist nur für die "empfohlene" Maximalzahl). Man denke mal daran, welche NAS-Geräte im Netz verkauft werden.

Aber auch abseits von diesem häufigen Nutzfall bringt Felix im "Enterprise"-Fall mal den Elefant im Raum auf den Punkt:
Ein Zettabyte an Daten zu speichern war das damalige Mem. Mehr als RAIDz3 zu bieten leider nicht.

Dass man für ein Zettabyte an Daten leider mehr als RAIDz3 braucht, und RAIDz3 auf entsprechend sehr vielen vdevs am Ende eine Ausfallwahrscheinlichkeit von ~1 bedeutet, ist halt mathematisch leider so. Damit kriegt man bei ZFS auch im "Hyperscaler"-Fall Probleme. "ZFS" ist schon vom Namen her (1 ZETTAbyte an Daten!1) wegen des gleichzeitigen Featuremangels (nur maximal RAIDz3) mit sich selbst inkonsistent.

Bei ZFS gibt es auch ein sich immer mehr entwickelndes Zielgruppenproblem:
*Auf der einen Seite die Hyperscaler, welche wegen der obigen Problematik gar nicht erst mit ZFS anfangen brauchen, und ihre eigene Lösung implementieren.
*Auf der anderen Seite die Unternehmen, bei denen
**sich im Rahmen des "big data"-Hypes der Jahre 2010-2020 herausstellte, dass die allergrößte "big data"-Datenbank dann doch nur 10 TiB groß war [0],
**oder so groß sind, dass sie das gar nicht mehr inhaus machen, sondern es auf den obigen Hyperscaler auslagern.

Die Schere der Datenmenge, die man speichern muss, geht dazwischen auseinander. Dazu kommt noch, dass die Festplatten immer größer werden, und man damit immer weniger Platten braucht. Für ~600 Euro gibt es 30-TiB-Platten (CMR) [1]. Herzlichen Glückwunsch, 99,9 % aller Nutzfälle im "Enterprise" sehen nun wie beim Heimanwender aus.

[0] https://motherduck.com/blog/big-data-is-dead/
[1] https://www.hardwareluxx.de/index.php/artikel/hardware/storage/66467-seagates-mozaic-3-im-test,-hamr-bei-exos-m-und-ironwolf-pro-mit-30-tb.html

>>159969
>Ein Zettabyte an Daten zu speichern war das damalige Mem
Sicher war es ein Mem.

Habe auch nie behauptet, dass ZFS perfekt ist. Vielleicht hast du den Teil überlesen – gut, ich sehe gerade, das war in dem anderen Faden – in dem ich schrieb, dass ich es ein bisschen bereue, ein FreeNAS gebaut zu haben:

>>159822
>Felix ist sich außerdem nicht mehr sicher, ob ZFS wirklich soooo überlegen ist, oder ob wir alle nur auf einen uralten Marketing-Gag von SUN reingefallen sind. Felix besitzt zwar ein FreeNAS, bereut es aber eigentlich, es gebaut zu haben.

Allerdings habe ich auch noch nichts gefunden, was wirklich besser ist als ZFS. Deshalb ja der Faden. Hier ging es eigentlich nicht darum, ZFS zu discotieren, sondern darum, welches Dateisystem der Felix von Welt heutzutage einsetzt.

Mit BCacheFS habe ich mich ehrlich gesagt bisher gar nicht beschäftigt. Habe das in meinem Gehirn wohl irgendwie mit F2FS zusammengeschmissen und dachte, das wäre etwas für SSDs. Ansonsten habe ich davon nur mitbekommen, dass es letztens aus dem Kernel rausgeflogen ist, also vielleicht ist es auch nicht so das Gelbe vom Ei?

>>159970
Bcachefs ist leider aktuell sehr schlecht:
https://www.phoronix.com/review/linux-617-filesystems/5

>>159971
D.h. ext4 immer noch #unbesiegt?

>>159970
Kent Overstreet war ursprünglich der Autor des Block-Caches bcache (der dazu diente, wie kommerzielle Hybrid-Festplatten Zugriffe auf langsame Blockgeräte wie Festplatten mit schnellen Blockgeräten wie SSDs zu beschleunigen) und hatte dann die glorreiche Idee, dieses Konstrukt zu einem integrierten Dateisystem zu erweitern, das es mit btrfs aufnehmen können sollte. Das Ergebnis (vor allem seiner Arbeitsmoral bezüglich Release-Zyklen) ist bekannt – viele gute Ideen, aber keine Disziplin zur Umsetzung.

Interessanterweise ist auch bcache inzwischen bekanntermaßen veralteter Murks, wenn man es unter Last setzt, ironischerweise häufig mittels btrfs im RAID1 oder mit aktivierter Deduplizierung. Der Arsch-Wiki-Artikel [0] ist voll mit roten Warnkästchen für nicht triviale Fallstricke.
>bcache is abandonware, and has artificial limitations (bucket generations < 128) that are only half-enforced, so it can create buckets that it refuses to then read.
>A busy BTRFS array can easily put bcache in a state where it refuses to start.
>BTRFS deduplication in particular has caused bcache to eat my data 3 times, even with writethrough mode.
Die alternative Lösung für einen Block-Cache ist heutzutage LVM mit einem Cache-LV.

[0] https://wiki.archlinux.org/title/Bcache

>>159981
>viele gute Ideen, aber keine Disziplin zur Umsetzung.
Fühlt bekannt

>>159982
Ist Kent ein Felix?
Dieser Felix hätte es bestimmt auch geschafft, sich mit Linus zu verkrachen.

>>159982
Lern endlich deine Fresse zu halten. Deine Ideen sind Müll. Du merkst es nur nicht, weil du nie das Ergebnis deiner halbausgegeronen Scheiße gesehen hast. Missgeborener kleiner Mongo. Kleine Klugscheißer die nie einen Tag gearbeitet haben, braucht niemand, aber dieses behinderte Drecksland ist voll davon. Alle totprügeln.

>>159997
Nein, die sind sehr gut. Das weißt du bloß nicht.

>>159997
Pillen nehmen.

>Rückaufs
bup

>>160024
Diese gut. Allerdings keine Putzfrau ohne manuelle Intervention.

>>160068
Felix scheißt da drauf und kauft alle Jubeljahre mal eine neue Platte. Solange die Plattenkapazitäten schneller anwachsen als Felix' gesammelten Backups, hat er mal wieder alle ausgedribbelt.

>>160069
Das Problem dabei ist ein wenig, dass Plattenpreise pro GB dabei gleich bleiben. vor 5 Jahren habe ich 4x4TB für irgendwas 500 Stutz gekauft, heute sind es etwa 500 Stutz für 16TB. D.h. wenn man alle Jubeljahre seine Plattenkapazität verdoppeln muss, muss man alle Jubeljahre doppelt so viel wie die letzten Jubeljahre bezahlen, das eskaliert exponentiell, in 1000 Jahren muss ich dann praktisch Millionen dafür zahlen, meine Plattenkapazität zu verdoppeln! Das kann doch nicht die Lösung sein!

>>160072
Felix konnte jahrzehntelang immer wieder für 100 Euro eine Festplatte mit doppelter Kapazität erwerben.
Und immer waren sie warm und lecker.

Heute nicht mehr.

>>160073
>Festplatte ... erwerben.
>Und immer waren sie warm und lecker.
>Heute nicht mehr.
Auch kalte Platten können leckeres bereithalten.

>>160072
>Stutz
Stutz dich selber du behinderter Schluchtenscheißer. Was für eine Missgeburtensprache. Sprich deutsch, du Mutterficker.

>>160087
Ui nei, hesch öppis nöd verstande? Du chasch ja grad nöd mal dr Stutz vom Rappen unterscheide, gäll? Mir lueged drum, dass du nöd no de Grind aneschlahsch bim Bünzli-Gstürm. Nimm e Schale, chumm abe, und lern erst mal rüüdig richtig Schwiizerdütsch, du halbbatziger Pief!

>>160089
Das ist keine Sprache, das ist ein Kehlkopfproblem.

>>160086
Find kalte Platte jetzt eigentlich eher nicht so geil, vor allem nicht um diese Jahreszeit.

>>160090
>DaS iScH kEi SpRaChE, dAs IsCh Es KeHlKoPfPrObleM.
Mach dir kei Sorg, mir hei im Migros sicher öppis dägegen – vielleicht en Ricola und e bitzli Erziehung. Du tötsch, wie wenn d’Grammatik di persönlich verlasse hätt. Chumm wider, wenn du wenigstens „Grüezi“ säge chasch, du arme Socke vom grossen Kanton.

>>160091
>Fefe_Radelt_2.jpg
Hey, den hast du von mir geklaut!

>>160089
>>160096
https://de.wiktionary.org/wiki/besorgt#%C3%9Cbersetzungen
(Man suche speziell nach den Übersetzungen für französisch, italienisch und rätoromanisch.)

>>160144
>Deutsch: besorgt
>Französisch: préoccupé
>Italienisch: preoccupato
>Portugiesisch: preocupado
>Rätoromanisch: preoccupà
>Spanisch: preocupado

Klasse! Darauf erst mal n Diäthunt.