I'm out, says OpenSUSE: We're dropping bcachefs support from next kernel version

The first distro vendor to announces its move says nein, danke

The next kernel will have no new bcachefs code – and the openSUSE versions that use that kernel are going further still.

The maintainers of openSUSE have made a decision over the future of the radical new bcachefs filesystem when openSUSE's distros are concerned: to disable it.

As we discussed in mid-August, the end of the battle between Linux paramount penguin Linus Torvalds and bcachefs boffin Kent Overstreet came to an unhappy conclusion. At the end of August, Torvalds announced that from now on, bcachefs is "externally maintained." As LWN summarized it, this means the new filesystem won't be developed as part of the main Linux kernel tree – but it hasn't been totally removed.

OpenSUSE, however, is going further: it will elimiate the new filesystem from its kernel builds. Jiří Slabý, who is one of SUSE's kernel maintainers, posted on the project's Factory list:

Given BCacheFS is "externally maintained" since 6.17, we are disabling the filesystem in 6.17 too. Therefore, everyone using it should follow the BCacheFS' upstream advises how to install/use it.

Anyone interested might also possibly prepare a KMP for themselves (and others).

The current 6.16.* is NOT affected. Neither is Slowroll (for now).

Once the BCacheFS maintainer behaves and the code is maintained upstream again, we will re-enable… (As IMO, it is a useful feature.)

(As an aside, Slabý later expressed regret that his English was too harsh, and apologized downthread. As it happens, this vulture used to work in SUSE in the Czech Republic, although not personally with Mr Slabý, and can attest that the Czech language can seem curt and abrupt when translated directly into English.)

Kernel 6.17 is not out yet – it's still in the release candidate stage; earlier this week, the developers released RC5. But as well as the stable, slow-moving openSUSE Leap, which moves in sync with the enterprise SLE, the openSUSE project maintains two rolling-release distros: the fast-changing openSUSE Tumbleweed and the still-experimental slower-release-cycle openSUSE Slowroll.

New kernel versions tend to appear roughly every two to three months, while even the faster-moving fixed-release distros tend to only release twice a year (such as Ubuntu interim releases and Fedora) to every other year (such as Debian). Rolling-release distros, though, continually get a trickle of new program versions as and when they're ready, meaning that they tend to get every kernel version at some point.

Bcachefs hasn't been removed from kernel 6.17: there's just no changes from the version of the code included in the current version 6.16. Something similar happened to version 6.13, as we reported at the end of 2024: none of Overstreet's changes were incorporated then, as a disciplinary move, and it shipped with the same bcachefs code as the subsequently declared LTS 6.12. It's too soon to say if the filesystem will be removed from 6.18.

Bcachefs being externally maintained out of sync with the main kernel doesn't stop anyone using it – it just means it will take a little more work. Being out-of-kernel doesn't prevent millions of machines from running Nvidia's Linux drivers, which are proprietary code and so can't be maintained in-tree.

The most common way is using the Dynamic Kernel Module System (DKMS), as the Arch wiki explains. DKMS watches for when the OS updates the kernel, and re-links the external code to make loadable modules for the new kernel version. This does work on openSUSE, but the SUSE family has been around for a third of a century, which means it has its own ways of doing things – in this case, its own mechanism called Kernel Module Packages.

Even so, while we can't blame the company for its decision, it's a small blow against bcachefs. In decades gone by, SUSE used to be a proponent of unusual and atypical filesystems. As this 2012 story from Linux.com describes, back then the company recommended ReiserFS, XFS, and Oracle's OCFS2.

Today, SUSE's clever transactional-updates feature depends on its Snapper subsystem, also used in Garuda Linux and rolling Debian variant siduction. Snapper in turn leans heavily on Btrfs (although it does also support thin-provisioned LVM). SUSE does not support the more mature COW-snapshot-capable OpenZFS, so in an ideal world, we would have liked to see it adopt bcachefs and make Snapper able to use bcachefs as well.

However, it does rather feel to us like recent SUSE products are dropping some of the distro family's familiar features, as we noted looking at the RC of Leap 16. This drops a number of traditional SUSE tools, such as the YaST system-admin tool and AutoYaST automated installation tool, as well as completely dropping 32-bit binary support and X.org.

We are not alone in this, as this recent comment by "DrillShopper" on Hacker News makes plain:

We use SLES15 at work and their bizarre decisions in SLES 16 to remove X servers (except for XWayland), remove 32-bit libraries, and complete removal of their AutoYaST unattended install tool in favor for a tool that is maybe 25 percent compatible with existing AutoYaST files still baffles me. We spent months moving to SLES15 from a RHEL derivative a few years ago and now we basically have to do it again for SLES16 with as big as the changes are. We have some rather strong integrations with the Xorg servers, and Wayland won't cut it for us currently, so we're stuck unless we want to re-architect 20 years of display logic to some paper spec that isn't evenly implemented and when it is, it's buggy as shit.

I've been pushing hard for us to move off SLES as a result, and I do not recommend it to anyone who wants a stable distribution that doesn't fuck over its users for stupid reasons.

We tried not to be quite so forthright, but we do sympathize. We are generally in favor for bold innovation in Linux world, but not to the extent that it removes the very attributes that gave a distro its unique qualities. ®