BFS is leaving the mainline kernel in Linux 7.4. Not the BeOS filesystem, which is BeFS and is staying. This BFS is the filesystem SCO UnixWare used for its boot partition.

What it could do

Very little, by design:

• Contiguous files only
• No subdirectories

A boot partition holds a kernel and some bootloader configuration. A flat directory of unfragmented files covers that completely, and there was no reason to build anything more capable.

The argument for removal

Ethan Nelson-Moore, who wrote the patch, made the case on grounds worth quoting because they are not the usual ones:

“Even though the bfs driver is very small and is unlikely to cause future maintenance problems, given that the only type of data stored on such a partition is likely to be kernels and bootloader settings, there is very little reason anyone would want to access it from Linux. Other old Unix filesystems (efs, freevxfs) have been removed recently, and bfs is highly unlikely to have any users, so remove it as well. Retain the UAPI header to be safe.”

Note the structure. He concedes the driver is small and not a maintenance risk, then argues for removing it anyway. The reasoning is about plausible use rather than cost: even someone with a UnixWare disk has no reason to mount its boot partition on Linux, because the only things on it are a UnixWare kernel and its bootloader settings.

Keeping the UAPI header is the careful part. Userspace headers are an interface, and deleting one can break a build somewhere far from the kernel. Removing the driver while leaving the header costs nothing and avoids a class of surprise.

The pattern

BFS follows EFS and FreeVxFS, both removed in 7.3. Three obsolete Unix filesystems out of the tree in two cycles is not a coincidence.

It connects to new guidance on which filesystems the kernel is willing to accept and carry. The concern is proliferation: every filesystem in the tree has to survive VFS changes, locking changes and API churn forever, and a filesystem nobody uses and nobody maintains still has to be updated by whoever is doing the tree-wide work. The cost lands on core maintainers rather than on the filesystem’s absent author.

That cost is real and usually invisible. It shows up as the person refactoring the VFS having to touch forty filesystems instead of eight, and having no way to test most of them.

The counter-argument

Removals like this always draw the same objection, and it is not a silly one. Once the code is gone, the data is unreadable without recovering an old kernel. Somebody with a genuine UnixWare archive now has a harder job than they did before.

The kernel’s answer is that this is what old kernels and virtual machines are for. Mount the disk under a 7.3 kernel in a VM, copy the files off, move on. Our KVM and QEMU guide covers the mechanics, and for a one-off recovery of a boot partition it is a reasonable answer.

It is a different calculation from EROFS disabling LZ4 rolling decompression over a corruption risk in the same cycle. That was a live filesystem with real users being made slower to keep it safe. This is a dead filesystem being removed because nobody is there.

Effect on you

None, unless you own SCO UnixWare hardware.

# what your kernel currently supports
cat /proc/filesystems

# what is built as a module
ls /lib/modules/$(uname -r)/kernel/fs/

If bfs appears in that list today, it will not on 7.4, and the absence will not affect anything you run.