BitBastelei

[@zwanzischmark]

Ton vom Intro ist da

[@romeorakow2977]

Danke für die umfangreiche Erklärung, hört sich sehr interessant an.

[@olafschermann1592]

Ist bcachefs bootbar? Oder nur data disk?

[@adlerweb]

Ich habe schon ein paar Meldungen gesehen, dass rootfs auf bcachefs wohl machbar ist.

[@deterdamel7380]

Schönes Video. Das letzte mal das ich zerlegende Dateisysteme hatte war noch zu Windows NT4.0/2000 Zeiten mit NTFS. extX, reiserfs3, btrfs, zfs, f2fs, xfs und modernere Versionen von NTFS haben bei mir nie Probleme gemacht.

[@adlerweb]

Zumindest zu 2012R2-Zeiten konnte ich da durch zu viele VSS-Operationen am Stück NTFS auch noch recht zuverlässig inkonsistent bekommen ;)

[@vbinsider]

Spannenderweise ist es bei mir eher ZFS, das sich unter Linux zerlegt hat. Daher nutze ich auf den Rechnern aktuell btrfs (innerhalb von dm-crypt) und das läuft rock solid. Schick ist, dass btrfs natives Backend für Docker sein kann. Mein Grund, überhaupt solche FS einzusetzen, ist ansonsten hauptsächlich der, dass du dadurch z.B. Quotas auf Verzeichnisebene machen kannst (indem du den Pool in separate Filesysteme unterteilst). Gleichzeitig muss man aber keine Partitionen oder logische Volumes managen und kann den Speicherplatz flexibel zuweisen, ohne sich da vorher festlegen zu müssen. Das war bei dem vorherigen Ansatz (ext4+LVM) immer der Krampf. ZFS wiederum läuft unter FreeBSD bislang absolut problemlos, evtl. ist es das OpenZFS, was da noch buggy ist.

[@OpenGL4ever]

Benutzt du ECC RAM? ZFS kann Fehler nicht verhindern, wenn das RAM nicht 100 % zuverlässig arbeitet.

[@vbinsider]

@@OpenGL4ever Tatsächlich nicht. Das war auf einem Notebook. Das RAM war aber danach getestet worden und in Ordnung.

[@OpenGL4ever]

@@vbinsider Auch funktionstüchtiges RAM kann Bitfehler verursachen. In dem Fall geschieht das dann durch Strahlung. Die einzige Rettung ist hier nur ECC RAM.

[@vbinsider]

@@OpenGL4ever Ja und wenn Vcore an der CPU im passenden Moment wackelt, kann auch ein Bit kippen und ZFS kann nix dafür. Ist alles richtig und die Effekte sind bekannt, die Erklärung taugt aber nicht dafür, die Praxistauglichkeit bzw. Robustheit der OpenZFS-Implementierung einzuschätzen. Ich halte die für nicht ausreichend für einen "daily driver". Diese Einschätzung passt ansonsten auch zu meiner Beobachtung, dass die ZFS-Implementierung in FreeBSD stabiler ist als die von Linux.

[@OpenGL4ever]

@@vbinsider Das will ich nicht ausschließen. Ich nutze ZFS ohnehin nur in TrueNAS (FreeBSD). Bei Linux nutze ich immer noch ext4.

[@thstein5592]

Wie stark ist das FS von dem einen Entwickler abhängig? Geht es weiter wenn der nicht mehr will oder kann?

[@LampJustin]

Soweit ich weiß entwickelt nur einer daran. Er ist an dem FS schon viele Jahre dran, weshalb ich in den kommenden Jahren nicht davon ausgehe, dass sich da was ändern würde. Ich hoffe aber natürlich, dass durch den Rutsch in den Kernel sich daran was ändern wird.

[@adlerweb]

Viele Projekte, an denen ganze Industriezweige hängen, sind oft in der Hand einiger weniger Maintainer, die den Laden in ihrer Freizeit am Laufen halten. Leider ist es üblich Open Source auch im großen Stil zu nutzen ohne sich finanziell an deren Entwicklung und Wartung zu beteiligen. Die massiven Lücken in vielen großen Softwarepaketen wie SAP, welche durch Log4j ausgelöst wurden, haben ja gezeigt, wie toll der Support ist. Viele Firmen beschwerten sich massiv oder bedrohten die Entwickler sogar, eine wirkliche Unterstützung beim Beheben des Fehlers konnte ich nirgends finden. Bei bcachefs war es bisher so, dass Mr. Overstreet bisher quasi Alleinherrscher war. Durch die Aufnahme in den Kernel bleibt er zwar mWn. der für dieses Subsystem zuständige Maintainer, es gibt nun aber deutlich mehr Kontrollen und Maßnahmen um im Zweifel auch ohne Ihn $dinge machen zu können. Das sowas auch funktionieren kann sieht man an ReiserFS - das wurde 2001(?) aufgenommen, 2008 fiel der Entwicker weg. Trotzdem kann man es auch heute noch nutzen. 2022 wurden Nutzer informiert, dass es eingestellt wird - es gibt inzwischen viele modernere Alternativen - trotzdem wird es bis 2025 noch mitgezogen und am laufen gehalten. Man hat als 3 Jahre Zeit das System zu Konvertieren oder die Daten auf ein neueres Dateisystem zu übernehmen, bis man keine Updates mehr installieren kann.

[@thstein5592]

@@adlerweb Danke für die Antwort. Die Aufnahme in den Kernel ist tatsächlich schon ein Schritt der vielversprechend ist.

[@Coksnuss]

Super Einblick! Vielen Dank. Ich nutze bisher btrfs aber nur auf einer einzigen SSD, bislang absolut problemlos. Für mich das Killerfeature sind snapshots. Für ein neues Setup würde ich aber bcachefs aufjedenfall mal ausprobieren.

[@elalemanpaisa]

Für snapshots kannst du auch LVM mit xfs nutzen

[@UloPe]

Danke, vor allem dass ich nun weiß wie es ausgesprochen wird. BCA-Chefs hat irgendwie wenig Sinn ergeben.

[@adlerweb]

Dabei klingt das noch eindeutiger als B-T-R-F-S. Äh, ButterFS,. Äh, B-Tree-FS. :D

[@mobacomp]

Rein zum Verständnis für mich ein paar Fragen: Ich nutze ZFS eigentlich Problemlos seit Jahren, was sind den deine Probleme beim Updaten ? Eventuell habe ich das bisher nie bemmerkt. Ich hatte schon mehrfach eine defekte Festplatte, aber noch nie einen Datenverlust, da ZFS das ja bemerkt beim schreiben. Es kommt halt Irgendwann die Meldung die Festplatte hat zu viele Schreibfehler. Ich habe das am Anfang zum Test sogar regelrecht gequält mit abziehen und aufstecken der SATA Kabel im Betrieb, hart abschalten beim schreiben usw. Klar der aktuell geschriebene Datensatz war eventuell weg, aber Datenverlust war Fehlanzeige. Das soll jetzt keine Diskussion werden, eher die Frage, worauf ich achten sollte. Wegen der Lizenz, sollte das mit OpenZFS nicht erledigt sein ? Ja OpenZFS ist noch nicht im Kernel integriert, aber selbst unter Opensuse klappt das bisher Fehlerfrei (Auf Holz klopf) Den Vorteil bcachefs , so habe ich das verstanden, ist die bessere Controlle wo Daten abgelegt werden und eventuell das Mischen unterschiedlicher HDD Größen. BTRFS rühre ich nicht mehr an, da hatte ich schon so viel Datenverlust. Das hat alle Chancen verspielt.

[@adlerweb]

Problem ist, dass ZFS bzw. ZOL mit Updates hinterherhinkt. Wenn es einen neuen Kernel gibt, welcher u.A. die API/ABI anpasst, dann dauert es meist 1-2 Wochen bis ZFS damit funktioniert. Bei größeren Versionswechsel dauerte es auch schon mal Monate. Da muss man dann jedes mal durchgehen, ob man den neuen Kernel zurückstellen kann oder man ggf. enthaltene Sicherheitsupdates selbst reinfummeln muss um das System nicht unnötig angreifbar zu lassen. Datenverlust hatte ich damit auch noch nicht. OpenZFS ist nur ein Fork des Originals und entsprechend auch unter CDDL statt gängigen Lizenzen wie GPL. Hierdurch kann der Code nicht in den Kernel selber aufgenommen werden. Es wird also immer ein Add-On sein, welches nicht automatisch getestet oder aktualisiert werden kann. Ja, bcachefs ist etwas flexibler was das Tiering angeht. BTRFS ist über die Jahre besser geworden, inzwischen habe ich nur noch sporadisch größere Bugs, aber leider sind auch heute Datenverluste da noch ein Problem.

[@m-electronics5977]

Replicas von 1 wäre dann ja RAID0 oder?

[@TilmanBaumann]

Ich benutze seit Jahren btrfs. Ohne Angst und Schaden. Aber bcacheds klingt interessant, ob sich ein Wechsel ohne Not lohnt muss ich mir noch überlegen

[@letsplaychannel6276]

Geht CoW aber nicht auf die Lebensdauer der SSD?

[@adlerweb]

Ich denke nicht, dass das einen nennenswerten Einfluss hat. Der Block muss ja so oder so neu geschrieben werden, Wear-leveling verteilt die Schreibvorgänge auch ohne CoW bereits über die Zellen, da man sonst eine höhere Abnutzung an einzelnen Stellen hätte.

[@letsplaychannel6276]

@@adlerweb Das Problem liegt so weit ich weiß eher bei den Metadaten die bei kleinen Datenblöcken mehr Schreibcyclen benötigen. Auch ext4 hat mit Journaling eine kleine write amplification aber das ganze soll z.B. auch bei Btrfs stärker ausfallen.

[@olafschermann1592]

Sehr cool. Dachte immer ZFS ist das optimum. Aber Sun=Oracle bedeutet Schwierigkeiten.

[@TilmanBaumann]

29:25 Nullbytes sind eventuell als sparse File erkannt und deshalb nicht komprimiert. Aber dann hätte sie Disk usage such quasi bei null sein müssen, insofern wohl auch nicht

[@adlerweb]

Jepp, das hatte mich an der Stelle auch verwirrt.

[@jensschroder8214]

Ich habe mit Amiga, Linux, Windows, OSX mich schon viel mit FS beschäftigt. (OFS, FFS, AFS, PFS, RaiserFS, ext-Varianten, FAT-Varianten, ExFat, NTFS, HFS-Varianten, APFS, ... ) Es ist immer eine Gefahr Daten auf ein seltenes und wohl möglich portieres FS zu legen. Irgendwann streckt der Computer wo alles lief die Flügel und die Daten müssen von einer anderen Computer gelesen werden. Dann ist es gut wenn es ein übliches FS ist und ich an die Daten noch ran komme. Ich verschlüssele meine FS grundsätzlich nicht, ich gebe meine Festplatten eben nicht heraus

[@adlerweb]

Daher hoffe ich auf bcachefs. Durch die Integration in den Kernel dürfte die Verbreitung steigen, da Open Source ist quasi ausgeschlossen, dass man später nicht mehr lesen kann. Verschlüsselt wird bei mir fast immer. Ich gebe zwar auch nichts raus, aber einige Kandidaten holen halt auch ab - sei es bei Einbrüchen oder im Falle von Mobilgeräten auch Unterwegs.

[@Memory1sRam]

@@adlerweb Genau deswegen verschlüssel ich ebenfalls. falls dieser (seltene) Fall mal eintreten sollte, muss ich mir keine unangenehmen Sorgen darüber machen, wer in meinen Daten schnüffelt oder evtl. meine privaten Daten der Welt verfügbar macht. Nutze seit Jahren LUKS mit ZFS drauf. Bisher in kein unlösbares Problem gerannt.

[@m-electronics5977]

8:17 wie tief beschäftigst du dich bitte mit den Dingen?

[@adlerweb]

Naja, einige der Meinungsverschiedenheiten waren sehr laut, ging zum Teil sogar durch die (Fach)Presse und führte zu einem Machtwort von Linus Torvalds.

[@m-electronics5977]

@@adlerweb OK, was auch immer das jetzt heißt😅

[@MrMotey]

Finde ich gehört zum üblichen Verfahren vor dem Einsatz neuer (open source) Software; Grobe Bewertung der Entwickler und deren Beziehung zur Community. Du willst dein System vielleicht nicht auf einer Software aufbauen, die nur von einem "schwierigen" Charakter geführt wird der z.b. Mitarbeit an "seinem Baby" aktiv verhindert und jedem mit Verbesserungsvorschlägen und/oder Fragen mit einem "YOUR DOING IT WRONG, MORON!" abspeist. Ich schaue z.b. immer auf die Menge der Leute die Contributen und in ein paar Issues stichprobenartig rein wie dort kommuniziert wird.

[@LampJustin]

Wie kommt's, dass sich dein BTRFS array zerlegt hat? In den letzten Jahren hatte ich echt 0 Problem. Hab sogar ein Resize von RAID1 zu RAID10 gemacht und nix ist passiert. Auch nutzen alle meine Laptops BTRFS als rootfs, allerdings natürlich nur im Single mode. Nutzt du den RAID5/6? Hattest du richtigen Datenverlust, oder konntest du es noch im ro mode mounten?

[@adlerweb]

Ich habe mich mit den meisten Ausfällen nicht weiter beschäftigt. Das war oft semi-zeitkritisch, da hieß es dann "backup zurück und gut" und es blieb keine Zeit mehr für eine genaue Fehleranalyse. Die meisten btrfs-Dinge sind bei mir single-device, für Größeres nutze ich bisher fast immer ZFS. Mir ging es da eher ums Checksumming und die Kompression. Der letzte Ausfall war auf einem Laptop. Dort ist während eines Kopiervorgangs (mit überschreiben) die Platte vollgelaufen. Statt die Write-Requests zu blockieren wurden diese aber eine Zeit lang noch weiter angenommen. Ergebnis war, dass das FS technisch noch komplett da und les/schreibbar war, alle Dateien, welche überschrieben werden sollten hatten aber nur noch Metadaten, waren also 0 Byte groß.

[@udirt]

Wann immer ihr über bcache und zugehörige Komponenten nachdenkt, testet erstmal das Replacement bei nem Ausfall des Cache Device. Und ob ihr Doku dazu findet.

[@adlerweb]

Ist ja auch immer von der Konfiguration abhängig. Man sollte natürlich nicht einfach eine SSD als (Schreib)Cache einbauen und Augen zumachen. Wenn, dann nur mehrere SSDs mit entsprechender Replikation oder den Cache auf Write Through zurückdrehen. Im Falle meiner kaputten SSD war es ein Write-Back mit Replication. Gab ab und an mal etwas höhere latency, wenn die SSD sich nochmal kurz meldete und daher wieder ein Versuch gestartet wurde, sonst war das aber ohne Datenverlust wie jede andere Sache auch.

[@m-electronics5977]

23:16 wie hast du das denn gemacht, das der die Nvme bezeichnung richtig macht?

[@zenja42]

Jup, mir hat btrfs ein RAID zerlegt, auf der synology tut es einfach. ZFS auf dem selben Controller mit Arch & PVE tut einfach bisher, selbst mein 60bay (6x10r2-4tb) tut einfach als SAN.

[@sku2007]

synology nutzt linux sw raid (mdadm) und darauf erst btrfs. die machen kein btrfs raid. steht in der synology knowledge base

[@franke5478]

@BitBastelei hast du mal einen Vergleich in Sachen Geschwindigkeit und CPU-Auslastung in Bezug auf mdadm gemacht? Das wäre mal interessant. (natürlich nur das, was sich auch vergleichen lässt; ein Mix aus SSD (zum schnellen Lesen/Schreiben und HDD zum speichern bei nichtgebrauch kann mdadm ja nicht) Danke 🙂

[@adlerweb]

Nicht wirklich, auf meinen Systemen verschwindet die Last von RAID-Implementierungen fast immer im Grundrauschen. Das ist ja eigentlich immer durch die Datenträger beschränkt, nicht durch irgendwelche Berechnungen.

[@m-electronics5977]

Du hast die Quotas vergessen!

[@tonyadvantaged9353]

Neue FS sind sehr interessant aber, m.M.n., die partitions-tools hinken ein bisschen dahinten. Was den boot-loaders angeht, da sieht noch schlimmer aus. Viele FS stellen die Arbeit ein nicht weil sie selbst kaputt gehen, sondern weil der boot-loader aussteigt. Die ganze Materie ist sehr komplex geworden und de facto nur für Experten geeignet. Die konkrete Fragen, auf die ich gerne ein Antwort hätte: 1. Liste von "Data-Carrier" die 4Kn bei "default" benutzen und/oder konvertieren kann. 2. Welche Typ von Partitionierung braucht ein 'bcachefs, btrfs, zfs' als "Unterbau" für Linux. 3. Wenn keine Partitionierung nötig sein soll, wie begrenze ich die "Partition", e.g.: meine nvme's sind alle (4) 1863 GiB groß (2TB) und/aber ich möchte nur 1860 oder 1800 GiB von jeden benutzen um einen einwandfreies Austausch zu gewährleisten. 4. Was von Boot-Loaders (grub, refind, zfsbootmenu) halten soll!? Grub ist (f. mich) obsolet, rEFInd hat keine implementierte ZFS-Treibern z.B. & ZFS-Boot-Menu... na ja ob der bcachefs booten kann !? Wäre sehr verbunden wenn ein bisschen mehr Klarheit über diese "kleine" Dinge gäbe. Die Video-Reihe finde ich, allerdings, sehr gut, danke dafür.

[@adlerweb]

Bootloader sind seit UEFI ja eigentlich gar nicht mehr nötig, man kann den kernel ja direkt booten. 1. Mir ist nicht ganz klar, was du meinst. Was 4k kann oder nicht ist ja vom Datenträger abhängig und dem FS eher egal. Da die Blockgrößen pro Device sind dürfte selbst mischen recht stressfrei sein. 2. Gebraucht wird für bcachefs keine, wenn man aber die Platte anderweitig aufteilen will (z.B. wegen einer ESP) ist der Typ egal, so lange Linux die Tabelle erkennen kann. UEFI mit 0FC63DAF-8483-4772-8E79-3D69D8477DE4 oder MBR mit 83 dürfte die übliche Wahl sein. 3. Ich würde es persönlich mit Partitionen lösen, alternativ könnte man eine quota setzen. Relevant ist das aber ohnehin nur, wenn man außerhalb von bcachefs dinge tun möchte. Wenn man über den vorgesehenen Weg geht werden ja nur belegte bereiche kopiert, so lange also das Dateisystem nicht zu 100% gefüllt ist, ist es egal wenn der Ersatz nicht 100% gleich groß ist. 4. Ich nutze - wie oben gesagt - direkt den Kernel über efibootmgr. Erzählungen sagen, dass das dann auch mit bcachefs funktionieren soll, wie eigentlich jedes Dateisystem, was im Kernel steckt oder sich in eine initrd packen lässt. Da ich bcachefs ausschließlich für Datenspeicher nutze und nicht davon boote hab ich das selbst aber noch nicht ausprobiert.

[@tonyadvantaged9353]

​@@adlerweb Nun, da Tools wie `gparted` o. `kpart` weder 4Kn Daten-Träger (DT) noch `bcachefs` o. `btrfs` o. `zfs` "unterstützen"… gestaltet sich die Partitionierung (Begrenzun der Partitionen), vorallem f. nicht Experten v. müsam bis unmöglich=ein f. moderne FS geeignet GUI-Tool existiert noch nicht. So, wenn ich ein Linux mit einer ESP/EFI v. 4 Gib & einer ROOT v. 1840 Gib installieren will, dann muss ich zumindest der DT partitionieren & vielleicht auch o. zum Teil formatieren & da `ext4` 4Kn nicht unterstützt… bleibt zumindest f. ROOT bei `btrfs` & `zfs` eine `BF00` = Solaris-Root Partitionierung übrig. Sache ist: Die GUI-Tools können nicht mal `vfat` mit der nötigen optionen f. 4Kn (Sektor-Größe 4096 b & nicht das alte 512 b o. 512e) partitionieren bzw. formatieren. Andere Formaten können diese Tools überhaupt nicht. ich würde wegen `bcachefs` überhaupt Nichts sagen, aber… wegen die seit 2012 4Kn-DT (4096 b Sektor) & `btrfs`- o. `zfs`-Unterbau (BF00) da sind diese Tools sehr rückständig. Nun, diese Frage stellt sich auch bei `bcachefs` wenn ich z.B. eine `/dev/sda1` mit 15 Gib haben will anstatt die vollen 20 GB o. GiB der gesamte `/dev/sda`. & zuletzt eine generelle Frage überder Unterbau der Partitionen: `FAT32`-Partition wird mit `vfat` (bei 4Kn) formatiert, aber, spielt bei Linux der Unterbau=Partition-Typ eine Rolle o. ist das ein Relikt der Vergangeheit als noch `ext4` "eingesetzt" wurde? Außerdem möche ich mich bei dir außerordentlich bedanken f. das ausführliches vorheriges Antwort, danke noch mal.

[@elalemanpaisa]

Fuer integrity bei Stromausfall reicht auch ein Journaling

[@adlerweb]

Jein, Journaling stellt nur die Integrität des Dateisystems sicher. Wenn man grade etwas am bearbeiten war kann die Datei trotzdem beschädigt werden. Durch COW kann dieses Editieren eine atomare Transaktion werden, man hat am Ende also auch nach einem Absturz entweder den kompletten Alten oder den neuen Stand.

[@elalemanpaisa]

@@adlerweb fair.. danke.. mich hätte in dem Video noch interessiert wie stabil das neue FS ist.. btrfs war ja viele Jahre Recht verrufen.

[@pedu71]

klingt echt gut, aber ich werde wohl eine ganze Weile auf Erfahrungsberichte warten. Wird schwer sein mich von 2 solo SSDs +LVM im RAID5 mit ext4 weg zu bekommen. Seit Jahren stabil trotz Hardwareausfällen HDs, gefühlte Verluste 0. Konnte ich in NTFS Zeit keineswegs sagen wegen inkonsistens. Größenänderungen LVM aber eher seltener, meist nur um mehr Platz zu reservieren. Windows 10 Partition schimmelt so vor sich hin. Mal sehen was es nächstes Jahr wird, vielleicht auch nur noch Laptop+NAS ext HDs

[@sku2007]

spannend, dass der zfs bug 15526 in den kommentaren nicht erwähnt wird :D ich verwende zfs auf server, nas und für backup (zfs send|receive). alles tip-top und bleibt auch so! aber mein lessons learned aus dem zum glück für meinen workload recht harmlosen bug ist, nicht mehr nur ein dateisystem zu verwenden. dateisysteme sind sw und sw hat bugs. daher ist für mich btrfs auf single hdd dazugekommen, ein weiteres folgt für offsite. 2x single hdd sollte reichen, da es die daten bereits mehrfach gibt. zum bug: soweit ich das verstanden habe, gibt es ein nach dem schreiben einer datei ein zeitfenster von einigen mikrosekunden (mikro!), wo man beim lesen mit "cp" ein paar 0 bytes bekommt. ein vor 1,5 jahren geänderter zfs parameter und ein vor monaten geändertetes verhalten von coreutils (wo cp dabei ist) haben den bug wahrscheinlicher gemacht, sodass er gefunden wurde. den bug an sich gibt es seit 10 jahren hatte ich gelesen. nochmal, ich meine nicht "nutzt das statt dem" sondern ich meine einfach nur "nutzt mehr als eines!"

[@adlerweb]

OK, der war mir bisher nicht bekannt. Bclone habe ich bisher noch nirgends eingeschaltet und würde bei meiner Workload ohnehin eher nicht auftreten, von daher für mich erst mal nicht sonderlich relevant. Aber natürlich kann ein Dateisystem - egal wie viel es verspricht - nie ein vernünftiges (und getestetes) Backupkonzept ersetzen.

[@berndschaub5905]

Vorweg, schönes Video, sehr ausführlich erklärt. Was ich nicht verstehe, warum muss in Linux immer alles etwas komplizierter gemacht werden, wenn es auch einfacher gehen könnte. Wenn ich die ZFS Befehle sehe, dann geht vieles in einem Rutsch. Gut finde ich das Erasure Coding bei BCACHEFS mit an Board ist. Stelle Dir mal eine FSTAB vor, wo ein 80 Platten System mit BCACHEFS eingetragen ist. Es muss nicht ZFS sein, aber bitte liebe Entwickler, macht die Befehle einfacher und kürzer. Ich hoffe das BCACHEFS eine Zukunft hat. Danke.

[@m-electronics5977]

6:20 die Doku von dem bcachefs ist aber richtig gut gegliedert👍👍

[@VinzentTPryce]

"spinning rust" 🤣

[@m-electronics5977]

Irgendwie weiß ich noch nicht so recht, was ich davon halten soll😬 ZFS ist einfacher irgendwie

[@MrMotey]

Findest du? Ich fand das hier jetzt alles ziemlich straight forward. Hat mir gefallen die Logik. Aber natürlich alles eine Frage von Gewohnheit und persönlichen Geschmack am Ende. Und ZFS, ist halt wie im Video erwähnt, in Berührung mit Oracle. Und alles was Oracle anfasst, mag ich nicht mehr anfassen :) Da kommt mir bcachefs gerade recht fürs nächste Storage-Projekt.

[@m-electronics5977]

@@MrMoteyhab jetzt doch angefangen mich damit zu befassen. Aber der braucht zum kompilieren des Kernels über 20GB storage und das sehe ich für ein 70-100M Linux Kernel Image nicht ein

[@W00PIE]

Sexy! 😍 ZFS ist leider unfassbar nervig, wie du ja schon erwähnt hast. Habe vor einiger Zeit mal versuchsweise eine Full Disk Encryption mit ZFS, UEFI und systemd-boot mit Arch Linux zu bauen (also mit einer ZFS encrypted root ohne luks), das hat auch eigentlich sehr schön funktioniert - leider nur, bis mir irgendein Update alles kaputtgetreten hat. Unter ARM sieht das momentan alles noch düsterer aus mit ZFS wegen dem ganzen Lizenzgeömpel, da vergeht einem komplett die Lust, sich weiter damit rumzuärgern. Wäre echt interessant, ob bcachefs schon bereit ist für den alltäglichen Einsatz mit Verschlüsselung. Macht auf jeden Fall Lust auf mehr, wenn man das so sieht!