bcachefs landet im Kernel 6.7

Message

schmidicom · Post by **schmidicom** » Tue Dec 12, 2023 6:15 pm

In letzter zeit passieren scheinbar einige interessante Dinge, nun gesellt sich auch bcachefs im offiziellen Kernel (ab Version 6.7) dazu.
https://www.phoronix.com/news/Bcachefs-Merged-Linux-6.7

Ich werde es gerne mal irgendwo ausprobieren, wo weiß ich noch nicht. Aber hat damit schon jemand erste Erfahrungen gesammelt?

EDIT:
Hier noch ein deutsches ziemlich aktuelles Video zu bcachefs, das ich persönlich als sehr gut empfand: https://youtu.be/LWI1apjTQl4

Post by **pietinger** » Tue Dec 12, 2023 10:05 pm

Nein, ich habe auch noch keine Erfahrungen damit gesammelt, bin aber gestern zufällig über dieses (deutsche) YT-Video gestolpert:
https://www.youtube.com/watch?v=LWI1apjTQl4

... und habe es mir komplett angesehen. Ja, ich finde es auch äußerst interessant ... falls es wirklich BTRFS und ZFS Konkurrenz machen sollte (für mich würde sonst nur EXT4 und XFS in Frage kommen).

Da war doch mal irgendwo in unserem Forum (im internationalen Bereich) ein Thread über Filesysteme (finde ihn grad' nicht) und der Tenor vieler war: Das wichtigste ist Stabilität == Datensicherheit.

Ja, BCACHEFS wird schon seit einigen Jahren entwickelt ... aber BTRFS noch viel länger ... und ich finde (fast) in jeder neuen Minor-Version des Kernels neue Patches für BTRFS ... nennt mich altmodisch - aber das weckt nicht mein Vertrauen in ein FS (über ZFS rede ich nicht) ... und ja, EXT4 hatte grade einen unseligen Zwischenfall weil ... ach was, ich bin jetzt wieder ruhig und freue mich, dass ich seit zwei Jahrzehnten keinen Zwischenfall mit EXT* hatte. Und vorher hatte ich nie ein Problem mit HPFS (unter OS/2).

firefly · Post by **firefly** » Wed Dec 13, 2023 8:10 am

pietinger wrote:ich finde (fast) in jeder neuen Minor-Version des Kernels neue Patches für BTRFS ... nennt mich altmodisch - aber das weckt nicht mein Vertrauen in ein FS (über ZFS rede ich nicht) ... und ja, EXT4 hatte grade einen unseligen Zwischenfall weil ... ach was, ich bin jetzt wieder ruhig und freue mich, dass ich seit zwei Jahrzehnten keinen Zwischenfall mit EXT* hatte.

Wenn man rein nach den anzahl der commits für ein FS pro kernel release geht, dann wären ein großteils FS nicht vertrauenswürdig. Obwohl vermutlich die meisten Commits einfach nur Wartungsarbeiten sind oder komplett neue features betreffen.
Es geht eher darum was die commits genau machen. Und ob es features betrifft, welche man selbst nutzt oder nicht.
z.b. BTRFS. Wenn es einige commits bezüglich Raid5/6 funktionalität gibtund man dieses Features nicht nutzt, haben diese commits, in diesem kontext, null aussage über das Vertrauen.

schmidicom · Post by **schmidicom** » Wed Dec 13, 2023 9:02 am

Zu BTRFS hat sich meine Meinung im laufe der Zeit halt auch deutlich verschlechtert und das teilweise auch wegen eigenen Erfahrungen.

Meine eigenen Erfahrungen:

Das Dateisystem ist am Anfang sehr schnell aber je länger es benutzt wird um so mehr fällt die Leistung spürbar ab. Und auch die aus dem Userspace in regelmäßigen Abständen ausgeführten Wartungs-Tools (welche zur Laufzeit wiederum selber die Leistung deutlich nach unten ziehen) wirken mehr wie schnell drauf geklebte Pflaster die nicht lange halten.
Dann gibt es da noch diesen einen, für mich zumindest, "legendären" Bug 89721. Der steht noch immer auf dem Status "NEW", er wird also noch nicht einmal offiziell anerkannt. Was zur Hölle ist das für eine Art mit gemeldeten Fehlern umzugehen?

Was man so liest:

Es gibt einige die bezüglich BTRFS die geradezu fürchterlichsten Erfahrungsberichte wiedergeben, was man davon letztlich glauben kann und was nicht ist eine andere Frage aber die Menge davon lässt schon kein gutes Gefühl aufkommen.
Hier mal ein beispiel für so etwas: http://coldattic.info/post/70/
Und einigen Blogs zufolge entspricht bei BTRFS die Codequalität auch nicht dem was im Linux-Kernel eigentlich üblich wäre, da fragen sich offenbar einige warum es das überhaupt in den Kernel geschafft hat.

Post by **pietinger** » Fri Jan 19, 2024 4:53 pm

Ich haben soeben von unserem Wiki-Editor @immolo diese Links bekommen, wo er bcachefs als rootfs für Gentoo nutzt:

Zweites Video mit Verschlüsselung der Root-Partition (erst ab Minute 3):
https://www.youtube.com/watch?v=lQ3natwvyVc

Erstes Video:
https://www.youtube.com/watch?v=JqifXUQ9O6s

firefly · Post by **firefly** » Fri Jan 19, 2024 5:18 pm

schmidicom wrote: Hier mal ein beispiel für so etwas: http://coldattic.info/post/70/

Öhm ein blog post von 2011 ist jetzt nicht gerade ein garant für aktuelle Informationen über ein stück software. Die Informationen sind 13 Jahre alt...

schmidicom · Post by **schmidicom** » Mon Jan 22, 2024 7:08 am

firefly wrote:
schmidicom wrote: Hier mal ein beispiel für so etwas: http://coldattic.info/post/70/
Öhm ein blog post von 2011 ist jetzt nicht gerade ein garant für aktuelle Informationen über ein stück software. Die Informationen sind 13 Jahre alt...

Gut geschriebene Artikel/Blogs zu dem Thema sind leider ziemlich selten und wenn btrfs wirklich "broken by design" ist dann dürften die 13 Jahre auch keinen Unterschied mehr machen.

firefly · Post by **firefly** » Mon Jan 22, 2024 9:37 am

schmidicom wrote:
firefly wrote:
schmidicom wrote: Hier mal ein beispiel für so etwas: http://coldattic.info/post/70/
Öhm ein blog post von 2011 ist jetzt nicht gerade ein garant für aktuelle Informationen über ein stück software. Die Informationen sind 13 Jahre alt...
Gut geschriebene Artikel/Blogs zu dem Thema sind leider ziemlich selten und wenn btrfs wirklich "broken by design" ist dann dürften die 13 Jahre auch keinen Unterschied mehr machen.

Naja die in dem blogpost angesprochenen Punkte sind aber keine die zeigen das btrfs "broken by design"sei.
Eher das es noch unoptimiert ist in der version zu dem zeitpunkt an dem die blogposts erstellt wurden und zum anderen, dass die Personen btrfs nicht verstanden haben.
btrfs verwendet "methoden", welche komplett anders sind zu den bisher bekannten Dateisystemen wie XFS oder ext4.

Das mit dem free space problem liegt daran, dass BTRFS Daten anders verwaltet (unter anderem um das raid features überhaupt implementieren zu können ohne dass dabei die Disks die selbe größe haben müssen! wie es bei mdadm der fall ist)
Eine gute Beschreibung zu diesem Problem und wieso es mit BTRFS auftreten kann und wie man es vermeidet findet man hier: https://wiki.tnonline.net/w/Btrfs/ENOSPC
Bezüglich Performance gibt es hier eine Beschreibung dass eine Änderung hier was verbessert hat (für gewissen workloads): https://wiki.tnonline.net/w/Btrfs/Free-Space-Tree