Bcachefs may be headed out of the kernel

Context of the dispute

• The immediate trigger is a bcachefs patch during the release-candidate (rc) phase that adds a new recovery option, framed by its author as critical data-loss mitigation but seen by others as a feature, not a pure bugfix.
• This reopens earlier tension: how an “experimental” filesystem should behave once it’s in mainline and subject to the same rules as mature subsystems.

Bugfix vs. feature and kernel process

• Kernel norms: after rc1, only narrowly scoped bugfixes are expected; new features and large refactors wait for the next merge window.
• Critics argue the recovery code is clearly a feature, increases risk surface late in the cycle, and undermines the discipline that keeps the rest of the kernel stable.
• Supporters argue that for filesystems, proper handling of data loss necessarily involves more than a minimal fix, and that aggressive iteration is needed to reach true stability.
• Several posters stress that even if the change were technically justified, repeatedly testing limits of the process destroys trust and forces extra scrutiny on every future pull.

“Experimental” status and user responsibility

• One side: bcachefs is marked experimental; users should not entrust it with irreplaceable data, and certainly not without backups. Therefore urgent “save everyone now” arguments are overstated.
• The other side: real users already store important data on it (often via distro kernels) and do not build custom kernels; getting robust recovery into mainline quickly both helps them and accelerates maturation.
• Some say if such users exist in numbers, there’s a communication failure about what “experimental” means.

Governance, maintainer behavior, and bus factor

• Many commenters are alarmed by a perceived “bus factor of 1” and by the maintainer’s repeated confrontations with kernel leadership; this makes people reluctant to adopt bcachefs for critical data.
• Suggestions include interposing another maintainer, treating bcachefs as an out-of-tree module until its process stabilizes, or even removing it from mainline if norms can’t be followed.
• Others counter that truly high-impact individual contributors are inherently harder to manage but often indispensable, and that outright ejection would harm both the project and the wider ecosystem.

Stable module API and out-of-tree options

• Some propose that a stable in-kernel module API would let bcachefs evolve on its own schedule.
• Kernel veterans reiterate the standard position that a stable module API would cement bad internal interfaces, encourage binary-only drivers, and harm long-term maintainability; LTS kernels are presented as the existing compromise.
• DKMS or distro-specific patching are mentioned as ways to ship faster filesystem changes without breaking kernel process, though several users describe DKMS as fragile for critical storage.

Comparisons with other filesystems

• btrfs: multiple reports in the thread of serious issues in multi-device/RAID modes (especially handling of temporarily missing devices and ENOSPC), and frustration with perceived under-prioritization of robustness versus performance/zoned storage. Others report years of trouble-free single-device use and point to official status docs.
• ZFS: widely regarded as robust but hampered on Linux by CDDL/GPL friction, out-of-tree status, and limitations (e.g., hibernation behavior). Still “good enough” for many production users.
• ext4/XFS: praised for maturity and performance but criticized for lack of modern CoW features like cheap snapshots and per-block checksumming of user data.
• APFS is repeatedly cited as evidence that other ecosystems have deployed modern, CoW, snapshotting filesystems broadly, raising pressure on Linux to have a comparable in-tree answer.

Architecture alternatives (FUSE, microkernels)

• Some argue this drama exemplifies the cost of putting filesystems in-kernel; with a strong user-space filesystem API (FUSE-like or microkernel-style), such work could iterate independently.
• Others respond that user-space filesystems still suffer from context-switch overhead and complexity, and that in practice Linux’s VFS + modules is already a form of evolving filesystem API.

Community sentiment

• A noticeable bloc believes removal from mainline would be justified if process violations continue; others see that as disproportionate and harmful given the promise of bcachefs.
• There is broad frustration that social friction and process conflict—rather than purely technical questions—now threaten what many hoped would be Linux’s “modern, safe, in-tree ZFS-class” filesystem.