Linux 7.4 removes BFS, the UnixWare boot file system

The Linux kernel is deleting its BFS file system driver in version 7.4. Ethan Nelson-Moore posted the removal patch to the kernel mailing list on September 4, 2026, and maintainer Christian Brauner has already queued it. It is the third old file system the kernel has dropped in two releases.

BFS here is the boot file system that SCO UnixWare used for its boot partition. UnixWare is a commercial Unix system, and Linux carried the driver so that such a disk could be read. Nelson-Moore's patch argues that "there is very little reason anyone would want to access it from Linux."

What the patch actually does

The patch touches 20 files. It deletes 6 of them and modifies 14, removing 1,275 lines and adding 4. The deleted files are the documentation, the Kconfig entry, the Makefile, the headers and the driver itself.

One file survives. The patch keeps include/uapi/linux/bfs_fs.h, the header that describes the on-disk layout to user-space programs. Removing a driver and removing its public header are separate decisions, and the kernel treats the second one as a break in its interface promise.

The stated reason is that almost nobody could be using it. "BFS is the filesystem UnixWare uses for its boot partition. It has extremely limited functionality, only supporting contiguous files and no subdirectories," Nelson-Moore wrote in the patch. The submission adds that "bfs is highly unlikely to have any users, so remove it."

Those two limits are worth pausing on. A contiguous file has to sit in one unbroken run of blocks on the disk. No subdirectories means every file lives in one flat list. That is enough to hold a kernel and a boot loader, and not much else.

Part of a wider cleanup

BFS is not the first to go. EFS and FreeVxFS were removed in Linux 7.3, the cycle immediately before this one. Phoronix reports that the removals follow new kernel guidance meant to reduce the burden of maintaining rarely used file systems in the tree.

The review went quickly. Brauner answered the patch with "I agree" and applied it. He wrote that it went to "the vfs-7.4.bfs branch of the vfs/vfs.git tree," and that "patches in the vfs-7.4.bfs branch should appear in linux-next soon." Lorenzo Stoakes, Jan Kara, Tigran Aivazian and Darrick J. Wong took part in the thread, and none of the visible replies opposed the removal.

What this means for developers

Check your mount table if you maintain forensic or migration tooling. A tool that reads old UnixWare disks by mounting them will stop working once your distribution ships a 7.4 kernel. Plan on a user-space reader or a copy of the last kernel that still has the driver.

Do not read the surviving header as a reprieve. bfs_fs.h stays because user-space interfaces are not removed casually, not because the driver is coming back. If your code includes that header and then calls mount, only half of it will still work.

Watch which file system is next rather than mourning this one. Three removals in two cycles is a pattern, and the stated test is maintenance cost against real users. If you depend on something obscure in the tree, the useful move is to say so on the mailing list now. The BFS thread shows how fast one of these goes from patch to queued when nobody objects.

There is a lesson here for anyone who ships a driver upstream. A driver with no visible users is a maintenance cost with no constituency, and the kernel has started charging for it. The way to keep a niche driver alive is to leave evidence that it is used, which means bug reports, test results and a maintainer who answers mail. Kernel work this cycle is full of the opposite case, such as AMD's Zen 6 making an existing mitigation unnecessary, where the hardware vendor is the one carrying the code.