Linux: Torvalds wirft Bcachefs-Dateisystem aus dem Kernel

Linus Torvalds hat den Support für Bcachefs aus dem Hauptentwicklungszweig seines Kernels entfernt; das in neun oder zehn Wochen erwartete Linux 6.18 wird mit dem Dateisystem formatierte Datenträger daher von Haus aus nicht mehr einbinden können. Der für Linux-Verhältnisse ungewöhnliche Rauswurf erfolgte rund 24 Stunden nach der Freigabe von Linux 6.17 zum Wochenstart. Diese Version hatte bereits keine Bcachefs-Neuerungen mehr gebracht, denn der Linux-Erfinder hatte den Stand dort vor zwei Monaten als „extern gewartet“ gekennzeichnet und damit eingefroren – nach mehrfachem Zank mit Kent Overstreet, dem Erfinder und Hauptentwickler von Bcachefs.

Bcachefs lässt sich jetzt via DKMS einrichten

Der Rauswurf sollte nur wenige Linux-Anwender betreffen, denn der Bcachefs-Code in Linux ist nie dem experimentellen Stadium entwachsen. Da einzelne Distributionen das Dateisystem aber als Option für Tester anboten, hat es durchaus Nutzer. Darunter sind auch einige sehr laute Fürsprecher. Kein Wunder, lockt doch Bcachefs mit einer attraktiven Kombination einiger von anderen Dateisystemen bekannten Features.

Für diese und zukünftige Anwender hat Overstreet einige Umbaumaßnahmen am Code vorgenommen, die er fortan extern entwickelt, wie er es vor der Aufnahme bei Linux 6.7 vor rund eindreiviertel Jahren getan hat. Durch die Umbauten lässt sich Bcachefs jetzt per DKMS (Dynamic Kernel Module Support) bei verschiedensten Kerneln ab Linux 6.16 nachrüsten – und wird bei Kernel-Updates idealerweise auch automatisch passend zum neuen Kernel übersetzt. Das Ganze kennen viele Anwender etwa von Distributionen wie Debian oder Ubuntu, die das ältere, proprietäre Kernel-Modul der Nvidia-Grafiktreiber via DKMS handhaben.

Auch zur Virtualisierung mit VMware oder VirtualBox oder zum Support des Dateisystem OpenZFS setzen viele Distributionen auf das unabhängig vom Kernel gewartete DKMS. Das funktioniert in vielen Fällen recht zuverlässig, fällt gelegentlich aber beim Kompilieren auf die Nase. Das liegt zumeist nicht an DKMS, sondern am eher monolithischen Design von Linux.

Bei dem sind Treiber, Dateisystemcode und nichts Separates, sondern formen zusammen den „Kernel“ – auch dann, wenn man beim Bau des Kernels festlegt, einige Teile als nur bei Bedarf nachgeladenes Modul auszulagern. Bei gängigen Linux-Distributionen passen Kernel-Module daher nur zu dem Kernel-Image, für das sie kompiliert wurden. Diese sind somit eben nicht ab- oder aufwärtskompatibel, wie man es von stabilen Plug-in- oder Add-on-Schnittstellen bei Browsern oder Treibern von Windows kennt.

Gefahr des „sich selbst Aussperrens“ durch instabile Schnittstellen

Das liegt auch an einem anderen Aspekt: Um den Kernel schnell und schlank zu halten, verändern Torvalds und seine Helfer bei Bedarf die Kommunikationswege zwischen den verschiedenen Bestandteilen von Linux; dabei nehmen sie keine Rücksicht auf externe gewarteten Kernel-Code, der sich über diese Wege einklinkt. Entwickler von extern entwickeltem Kernel-Code wie fortan Bcachefs müssen diesen daher hin und wieder an die Belange neuer Linux-Versionen anpassen; das kann alle paar Wochen oder nur alle paar Jahre nötig sein, je nachdem, welche Kernel-Funktionen der externe Code verwendet und wie häufig sich diese Kernel-seitig ändern.

Diese Änderungen am externen Code müssen es dann aber auch zu den Nutzern schaffen, bevor diese auf Kernel-Version mit veränderten Schnittstellen wechseln. Hakt es daran, schlägt beim Anwender das automatische Kompilieren des Moduls via DKMS fehl.

Bei extern gewarteten Modulen für Grafikchips führt das zu Problemen, die zumindest Kenner oft mit einigen Handgriffen lösen können. Bei Modulen für Dateisysteme kann es schwieriger sein, denn wenn dem startenden Kernel ein Modul für das Root-Dateisystem fehlt, kann man das System darüber nicht mehr starten und daher kein passendes neues Modul einrichten. Um sich aus so einer Situation ohne Live-Linux heraus zu manövrieren, belassen einige Distributionen den jeweils letzten als funktionierend bekannten Kernel bei Updates als Boot-Option zurück. Derlei braucht man im dümmsten Fall auch, wenn neuer Modulcode nicht funktioniert und man das alte Modul schon gelöscht hat.

Distributions-spezifische Anpassungen erschweren die Auslieferung

Der DKMS-Weg von Bcachefs hat einen weiteren Nachteil, wie Overstreets Mail zur breiten Verfügbarkeit des DKMS-Ansatzes zeigt: Statt Bcachefs mehr oder weniger frei Haus über den Kernel an Distributionen zu verteilen, sind nun Anpassungen für Eigenarten der verschiedensten Distributionen nötig. Zur möglichst einfachen Handhabung durch die Nutzer braucht es ferner idealerweise auch Distributions-spezifische Pakete, die jemand konstant pflegt und testet.

Beim Support für Arch Linux, Debian und Ubuntu scheint die Lage demnach schon recht gut zu sein. Bei Fedora ist es im Werden, während bei openSUSE noch allerlei Fragezeichen im Raum stehen; dessen Entwickler hatten kürzlich den Bcachefs-Support bei Tumbleweed-Kernel beim Wechsel auf 6.17 deaktivierten und Overstreets Verhalten dabei kritisierten.

DKMS ist der Grund für den schnellen Rauswurf

Die Bcachefs-Unterstützung zur Handhabung via DKMS nennt Torvalds jetzt als Grund für die Entfernung des Dateisystems – die Kenner mittelfristig erwartet hatten, aber letztlich jetzt viel flotter kam, als es bei der Stilllegung von Bcachefs vor zwei Monaten schien. Der waren mehrere Streitereien vorangegangen, vor allem zwischen Overstreet und Torvalds. Gleich zweimal hatte es zwischen den beiden lautstark gekracht, weil der Bcachefs-Erfinder Code mit neuen Features zur Aufnahme während der längeren Stabilisierungsphase an den Linux-Erfinder schickte, anstatt während der kurzen Hauptentwicklungsphase (dem „Merge Window“), die dafür vorgesehen ist. Overstreet war aber auch mehrfach mit anderen Entwicklern zusammen gerasselt. Unter anderem, weil er hinterrücks den von ihnen betreuten Code geändert hatte.

Der streitbare Kalifornier hat Bcachefs seit über zehn Jahren weitgehend im Alleingang entwickelt – auch, weil sich mehrere mit der Zeit dazu gestoßene Mitstreiter über kurz oder lang mit ihm überworfen haben. Bis zu einem gewissen Grad ist das nur menschlich, schließlich passiert derlei auch beim Hasenzüchter- und Sportvereinen; bei Häufigkeit und Tonfall der Streitereien hebt sich die Bcachefs-Entwicklung aber negativ von anderen Software-Projekten und auch dem Linux-Kernel ab.

Dateisystem-Entwicklung ist hart

Derlei Drama und der Zank mit zentralen Kernel-Entwicklern dürften Schwergewichte aus dem Linux-Bereich verschrecken, die jährlich schätzungsweise mehrere Millionen von US-Dollar in Hardware und Mitarbeiter investieren, um die direkt in Linux enthaltenen Dateisysteme zu testen und zu verbessern – etwa Google (Ext4), Meta und Suse (Btrfs) oder Oracle und Red Hat (XFS).

Für Overstreet und seine Unterstützer wird es schwer, da mitzuhalten, denn Dateisysteme sind komplex und Linux-Nutzer machen die kuriosesten Dinge mit ihnen – daher sind meist viele Jahre Feldtest und mühsames Feintuning nötig, bis ein universelles Dateisystem wie Bcachefs wirklich stabil und in vielen der gängigen Einsatzgebiete performant arbeitet.

Hier hat Bcachefs noch viel Arbeit vor sich, auch wenn sein Hauptentwickler den extern gewarteten Dateisystemcode kürzlich als „stabil“ deklariert hat. Zumindest, wenn es ähnlich wie bei der Entwicklung von Btrfs, Ext4, Reiserfs oder XFS läuft: Auch dort war ab einem vergleichbaren Punkt noch jahrelange Arbeit und damit letztlich auch viel Geld nötig, um die Erwartungen der breiten Anwenderschar an Robustheit und Performance zu befriedigen.

(ktn)