Bcachefs removed from the mainline kernel

Status After Removal & DKMS Transition

• Bcachefs has been removed from mainline but continues as an out‑of‑tree DKMS module.
• Previously it depended on core kernel changes, requiring custom kernels; now it can be built for “recent enough” stock kernels.
• Some see this as a net positive for flexibility; others note it reintroduces the classic out‑of‑tree pain (rebuilds, breakage, secure‑boot key enrollment on many machines).

Kernel Policy, External Modules, and ZFS Precedent

• Strong reminder: the kernel community does not commit to any ABI for external modules and actively removes unused exports, even if that breaks ZFS or similar.
• Example discussed: removal or GPL‑only re‑export of FPU symbols that broke ZFS, justified by “no exports without in‑kernel users.”
• Debate over whether this is “removal” or “API change,” but consensus that out‑of‑tree consumers cannot rely on stability.
• Long digression on ZFS/CDDL vs GPL, Oracle/Sun intent, and OpenZFS being stuck with CDDL despite wanting Linux interoperability.

Why It Was Removed: Process vs. Technology

• Most agree the removal was not about bcachefs design or “instability” per se but about repeated process conflicts.
• Pattern described: large, late pull requests during -rc with bugfixes plus new features (notably recovery tooling), after the merge window closed.
• Bcachefs maintainer argued these were critical for data recovery and that treating them as mere “features” was unacceptable.
• Kernel leadership saw this as abusing the -rc bugfix window, ignoring requests to slow down and separate changes, plus prior incidents of abrasive communication.
• Many characterize the final decision as a leadership/behavior issue after “too many” exceptions and arguments, not a single incident.

Stability, Production Use, and Real‑World Reports

• Experiences diverge: some report multi‑year, multi‑device bcachefs deployments with no unrecoverable loss; others are wary due to high patch churn and YouTube/blog coverage of controversies.
• Several commenters would not yet trust it for hundreds of production machines; others argue its real‑world data‑loss record is better than its reputation.
• Confusion over “experimental” label: some assumed it only meant “might eat data,” not “might be removed from mainline quickly.”

Performance and Benchmarks

• Initial Phoronix benchmarks showed very poor performance versus btrfs/ZFS, leading to concern.
• Critics note configuration issues (e.g., 512‑byte block size, possible fsync path problems).
• Later DKMS benchmarks show much better numbers, apparently due to optimizations that never made it upstream before removal.

Alternatives: ZFS, Btrfs, and Layered Stacks

• Many still want a robust in‑kernel COW filesystem with checksums, snapshots, parity RAID, and simpler administration than mdraid+LVM+ext4.
• ZFS is praised for reliability, features, and ease of pool/drive management, but its licensing and out‑of‑tree status are major drawbacks.
• Btrfs splits opinion: some report years of trouble‑free use (especially single‑device or on rock‑solid block layers); others recount repeated corruption, RAID5/6 warnings, space‑full disasters, and Synology/SOHO horror stories.
• Several argue that complexity of layered stacks (mdraid + LVM + ext4/btrfs) is itself a reliability and operability problem bcachefs was meant to solve.

Governance, Process, and Community Future

• Some think Linus should have enforced the rules more strictly earlier; others say he was already unusually patient and this is what finally “telling him to take a hike” looks like.
• There is sympathy for both sides: kernel maintainers needing scalable process vs. a filesystem maintainer prioritizing rapid fixes for data‑eating bugs.
• Some sponsors and early adopters feel burned and question project maturity; others continue to fund and use bcachefs and highlight an increasingly active community around the DKMS path.
• A recurring theme: technology is widely respected; the main obstacle to re‑merging is human/process, and it’s unclear if or when that will be resolved.