Entfernung des Bcachefs-Codes aus dem Kernel: Was das für die Zukunft des Dateisystems bedeutet

Bcachefs wurde aus dem Linux 6.18-Kernel entfernt und nahm 117.000 Zeilen Code mit. Linus Torvalds‘ Entscheidung ist der Höhepunkt von zehn Jahren Hin und Her zwischen Patches, Tests und Meinungsverschiedenheiten. Für Administratoren stellt sich die Frage: Weiter mit externen Modulen oder zurück zu den klassischen Versionen Ext4, XFS und ZFS? Der Zeitpunkt ist alles andere als trivial. DKMS-Pakete sind gerade in den Debian-, Fedora- und Ubuntu-Repositories gelandet und ersparen produktiven Nutzern so einen „Schwarzen Montag“. Es bleibt abzuwarten, was diese Entfernung über die Kernel-Governance und, noch wichtiger, die Zukunft von Dateisystemen aussagt. Abrupte Entfernung von Bcachefs aus dem Linux 6.18-Kernel: Die wahren Gründe Der Grund dafür war ein Konflikt über den Programmierstil und die Kommunikation zwischen Kent Overstreet und dem Kernteam. Linus Torvalds tolerierte die Integration in 6.7 zunächst, um sie zu sehen, fror dann aber Beiträge ab 6.17 ein. Das nächste Merge-Fenster bestätigte das Urteil: schlichte und einfache Entfernung. Offizielles Argument: „Um Verwirrung zu vermeiden“, da das DKMS-Modul bereit ist. Inoffiziell ist es eine Erinnerung daran, dass kein Projekt den kollaborativen Prozess ignorieren kann, egal wie vielversprechend er ist. Als Bonus spart der Kernel 350 KB auf dem ISO – ein Wink an diejenigen, die immer noch auf einen minimalistischen Boot schwören.

Unmittelbare Auswirkungen auf Red Hat, Canonical und Derivate Red Hathatte Bcachefs nie standardmäßig aktiviert und bevorzugte die von RHEL übernommene Vorsicht. Canonical diskutierte es für seinen „Ubuntu Pro“-Installer, setzte aber bereits auf ZFS für die native Verschlüsselung. Auf Fedora-Seite enthielten Nightly Spins Bcachefs seit März; Fedora 40 wird daher auf ein DKMS-Modul umsteigen, wie das aktuelle Debian Sid. Das Risiko? Ein Kernel-Upgrade, bei dem vergessen wird, das Modul auf einem Produktionsserver neu zu kompilieren. Die Betreuer empfehlen, die Version zu sperren oder Ansible zu verwenden, um das Vorhandensein der .ko-Datei nach jedem Neustart zu überprüfen. Ein Vorgang, den manche seit den Tagen der Nvidia 96xx-Treiber nicht mehr erlebt haben.

Bewährte Alternativen: Ext4, XFS und ZFS setzen Maßstäbe

Laut der StackShare-Umfrage wird Ext4 auch 2025 die Standardlösung für 80 % der Serverinstallationen bleiben. Seine Robustheit und der geringe CPU-Overhead machen es für containerisierte Workloads unschlagbar.

XFS

gewinnt dank seiner hervorragenden zusammenhängenden Zuordnung bei Implementierungen mit sehr großen Dateien.

ZFS behält die Vorteile von Snapshots und Online-Deduplizierung, auch wenn die CDDL-Lizenz die Mainline-Integration weiterhin einschränkt. Aktuelle Benchmarks auf Ryzen 9000 zeigen einen Unterschied von nur 3 % bei sequenziellen Lesevorgängen im Vergleich zu Bcachefs – ein vernachlässigbarer Unterschied im Vergleich zum Komfort des offiziellen Supports. Sollten Sie migrieren oder bei Bcachefs als DKMS-Modul bleiben? Cluster, die bereits Bcachefs verwenden, sind nicht zum Scheitern verurteilt. Das DKMS-Modul kompiliert in 40 Sekunden auf einer vCPU und ist bis Kernel 5.15 LTS kompatibel. Jedes größere Upgrade wird jedoch zu einem manuellen Kontrollpunkt: Wiederherstellungstest, RAID-Neuaufbau, Prüfsummenvalidierung. Die Versuchung, zu Ext4 zurückzukehren, ist für kleine Teams groß. Der Verzicht auf CoW und Prüfsummen vervielfacht jedoch die Schreibvorgänge und den SSD-Verschleiß. Der plausible Kompromiss: Konvertieren Sie kritische Volumes in ZFS und behalten Sie Bcachefs für flüchtige Objekt-Caches bei, wo seine LZ4-Komprimierung weiterhin glänzt.Diese Saga enthüllt die Kultur des Linux-Kernels.

30 Jahre lang hat sich der Kernel mit einer Geschwindigkeit von einem Patch-Set alle neun Sekunden weiterentwickelt. Linus Torvalds erinnerte uns daran: Die Tür steht jedem Code offen, aber die Debatte bleibt öffentlich und manchmal hitzig. Bcachefs ist weder der erste noch der letzte, der diese natürliche Selektion erlebt hat; erinnern Sie sich an Reiser4 oder Tux3.

Die Community wertet diese Entfernung als klares Signal: Anzahl und Qualität der Tests haben Vorrang vor der Brillanz eines Designs. Subsystem-Betreuer begrüßen dies, da der Rückstand bei den Speicherfehlern bereits abnimmt. Ironischerweise verleiht der Hype um die Entfernung Bcachefs eine Sichtbarkeit, die sein ursprüngliches Commit nie hatte.

Wird es jemals zurückkehren? Kent Overstreet hat sein letztes Wort noch nicht gesprochen. Er arbeitet an einem „bcachefs-next“, das sich an den Stil- und Testkonventionen des Kernels orientiert. Wenn es ihm gelingt, eine Task Force von Prüfern zu mobilisieren, könnte sich die Tür zu 6.20 wieder öffnen. In der Zwischenzeit müssen Administratoren wählen: DKMS-Releases im Auge behalten oder ihre Volumes mit den drei historischen Säulen festigen. In einer Welt, in der jede Millisekunde an I/O zählt, wird die Entscheidung nicht leichtfertig getroffen, aber die Odyssee des freien Speichers geht mit Patch für Patch weiter. Quelle:linuxnews.de