Why Linux Kernel 6.16 Might Be the Last Release to Support Bcachefs

Background

Linus Torvalds warned that Linux kernel 6.16 may be the last release that includes the new‑style Bcachefs file system, and that Bcachefs could be removed from the mainline starting with the 6.17 merge window.

Bcachefs overview

Bcachefs is a copy‑on‑write (COW) file system for Linux developed by Kent Overstreet. It reuses about 80 % of the code from the earlier block‑caching layer Bcache (also created by Overstreet). After roughly a decade of development, Bcachefs was merged into the mainline kernel in version 6.7 (early 2024). The project aims to combine ZFS/Btrfs‑style features (snapshots, checksums, compression, deduplication) with the performance characteristics of ext4 and XFS.

Since its inclusion, the subsystem has exhibited a high frequency of bugs and regressions, prompting repeated maintenance effort.

Kernel development flow relevant to the dispute

The Linux kernel follows a strict release cycle:

Merge window (≈2 weeks) – new features and major changes are accepted.

Release‑candidate (rc) series – only bug‑fixes to code merged during the window are allowed.

Final release – after the rc series is deemed stable.

Violating the “rc‑only‑bug‑fix” rule is considered a serious breach of process.

Journal‑rewind patch

During the 6.16‑rc3 period Kent Overstreet submitted a patch named journal‑rewind . The patch:

Modifies >1,000 lines across the Bcachefs code base.

Introduces a new “journal rewind” operation intended to repair corrupted Bcachefs journals reported by users.

Is technically a new feature rather than a pure bug‑fix.

Because the patch was submitted after the merge window closed, Linus Torvalds rejected it as a rule violation, stating that “the purpose of the merge window is to prevent exactly this kind of late‑stage feature addition.”

Discussion and positions

Linus Torvalds temporarily merged the patch to avoid breaking existing users but warned that Bcachefs would likely be dropped in the 6.17 merge window if the maintainer continued to submit out‑of‑process changes. He emphasized that loss of confidence in a subsystem permits him to reject all future contributions.

Ext4 maintainer Theodore Ts’o publicly supported Linus, noting that the rc phase is not the place for large, risky modifications, especially for a file system that handles user data.

Kent Overstreet argued that the journal‑rewind change was essential for data integrity and that strict adherence to the rc rule would leave a critical bug unfixed. He also suggested that a co‑maintainer could help manage submissions and reduce interpersonal friction.

Potential outcomes

If Bcachefs is removed from the mainline, developers have three practical alternatives:

Build a custom kernel that includes the Bcachefs source tree (the code resides under fs/bcachefs in the kernel source).

Use the user‑space FUSE implementation of Bcachefs, which runs outside the kernel but incurs performance overhead.

Deploy DKMS (Dynamic Kernel Module Support) to compile the Bcachefs module on demand for each kernel version.

These paths allow continued experimentation without relying on upstream inclusion.

Implications

The episode underscores the importance of respecting the established kernel development process. It also highlights the challenges faced by experimental file systems attempting to gain mainline acceptance, especially when maintainers have limited collaboration bandwidth.