Linux 7.4 entfernt BFS, das Boot-Dateisystem von UnixWare

Der Linux-Kernel löscht in Version 7.4 seinen Treiber für das Dateisystem BFS. Ethan Nelson-Moore schickte den Entfernungs-Patch am 4. September 2026 an die Kernel-Mailingliste, und der Maintainer Christian Brauner hat ihn bereits eingereiht. Es ist das dritte alte Dateisystem, das der Kernel in zwei Releases fallen lässt.

BFS ist hier das Boot-Dateisystem, das SCO UnixWare für seine Boot-Partition benutzte. UnixWare ist ein kommerzielles Unix-System, und Linux trug den Treiber, damit eine solche Platte gelesen werden konnte. Der Patch von Nelson-Moore argumentiert, dass es "very little reason anyone would want to access it from Linux" gebe.

Was der Patch tatsächlich tut

Der Patch berührt 20 Dateien. Er löscht 6 davon und ändert 14, entfernt 1.275 Zeilen und fügt 4 hinzu. Gelöscht werden die Dokumentation, der Kconfig-Eintrag, das Makefile, die Header und der Treiber selbst.

Eine Datei überlebt. Der Patch behält include/uapi/linux/bfs_fs.h, den Header, der das Format auf der Platte für Programme im User-Space beschreibt. Einen Treiber zu entfernen und seinen öffentlichen Header zu entfernen, sind zwei getrennte Entscheidungen, und der Kernel behandelt die zweite als Bruch seines Schnittstellen-Versprechens.

Der angegebene Grund ist, dass es kaum noch Nutzer geben kann. "BFS is the filesystem UnixWare uses for its boot partition. It has extremely limited functionality, only supporting contiguous files and no subdirectories", schrieb Nelson-Moore im Patch. Die Einreichung ergänzt, dass "bfs is highly unlikely to have any users, so remove it".

Bei diesen beiden Grenzen lohnt ein kurzer Halt. Eine zusammenhängende Datei muss in einem ununterbrochenen Block-Lauf auf der Platte liegen. Keine Unterverzeichnisse heißt, dass jede Datei in einer einzigen flachen Liste steht. Das reicht für einen Kernel und einen Bootloader, und für viel mehr nicht.

Teil eines größeren Aufräumens

BFS ist nicht das erste, das geht. EFS und FreeVxFS wurden in Linux 7.3 entfernt, im Zyklus direkt davor. Phoronix berichtet, dass die Entfernungen neuen Kernel-Leitlinien folgen, die den Aufwand für selten genutzte Dateisysteme im Baum senken sollen.

Die Prüfung ging schnell. Brauner antwortete auf den Patch mit "I agree" und übernahm ihn. Er schrieb, er sei in "the vfs-7.4.bfs branch of the vfs/vfs.git tree" gegangen, und dass "patches in the vfs-7.4.bfs branch should appear in linux-next soon". Lorenzo Stoakes, Jan Kara, Tigran Aivazian und Darrick J. Wong nahmen am Thread teil, und keine der sichtbaren Antworten sprach sich gegen die Entfernung aus.

Was das für Entwickler bedeutet

Prüfen Sie Ihre Mount-Tabelle, wenn Sie Werkzeuge für Forensik oder Migration pflegen. Ein Werkzeug, das alte UnixWare-Platten durch Mounten liest, hört auf zu funktionieren, sobald Ihre Distribution einen 7.4-Kernel ausliefert. Planen Sie einen Leser im User-Space ein, oder eine Kopie des letzten Kernels mit diesem Treiber.

Lesen Sie den überlebenden Header nicht als Aufschub. bfs_fs.h bleibt, weil Schnittstellen zum User-Space nicht leichtfertig entfernt werden, nicht weil der Treiber zurückkommt. Wenn Ihr Code diesen Header einbindet und dann mount aufruft, funktioniert davon nur die Hälfte weiter.

Achten Sie darauf, welches Dateisystem als Nächstes dran ist, statt diesem nachzutrauern. Drei Entfernungen in zwei Zyklen sind ein Muster, und der genannte Maßstab ist Pflegeaufwand gegen echte Nutzer. Wenn Sie von etwas Obskurem im Baum abhängen, ist es jetzt sinnvoll, das auf der Mailingliste zu sagen. Der BFS-Thread zeigt, wie schnell so etwas vom Patch zur Warteschlange wird, wenn niemand widerspricht.

Für alle, die einen Treiber nach upstream bringen, steckt hier eine Lehre. Ein Treiber ohne sichtbare Nutzer ist ein Pflegeaufwand ohne Fürsprecher, und der Kernel stellt das inzwischen in Rechnung. Einen Nischentreiber hält man am Leben, indem man Spuren der Nutzung hinterlässt: Fehlerberichte, Testergebnisse und ein Maintainer, der auf Mails antwortet. Die Kernel-Arbeit dieses Zyklus ist voll vom Gegenteil, etwa AMDs Zen 6, das eine bestehende Mitigation überflüssig macht, wo der Hardware-Hersteller den Code trägt.