/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.