Migrating Away from Bcachefs
An experimental Linux filesystem, bcachefs, is drawing both enthusiasm for its performance and features and concern over its maturity, on-disk format changes, and suitability for production use. Commenters debate how distributions like Debian should package such rapidly evolving tools, especially around Rust dependency policies, and who bears responsibility when downstream changes introduce bugs. Underlying it all is a tension between the desire to move fast to stabilize a new filesystem and the need for conservative processes, clear support boundaries, and respectful collaboration with users and distro maintainers.
Status of bcachefs and Appropriate Use
- Widely described as still “experimental”; several commenters say it belongs on test, cache, or gaming machines, not important data yet.
- Some are waiting to migrate from ZFS or other filesystems but won’t risk main systems until it’s declared stable.
- There is debate over how long “6 months to non‑experimental” has been claimed; some see stability timelines as optimistic.
User Experiences and Bug Handling
- Multiple users report very fast bug fixes and positive direct interactions with the maintainer.
- Others describe bug reporting as unpleasant or confrontational, enough to sap the “fun” out of experimentation.
- There is tension between fixing issues quickly versus following slower, more conservative kernel processes.
Debian, Rust Dependencies, and Packaging Policy
- Major thread around a Debian packaging incident:
- Debian relaxed or altered Rust dependency versions and debundled libraries against upstream’s advice.
- This allegedly broke builds and delayed critical fixes (e.g., mount options, degraded-mode mounting).
- Users hit issues, but bug reports flowed to upstream rather than to the distro.
- Some argue distros assume maintenance responsibility when they modify dependencies; others note, in practice, users still go upstream.
- Upstream now strongly prefers no unbundling and is fine with delaying or avoiding inclusion in distros until things are more mature.
- Suggested mitigation: clearly document supported versions, use issue templates, and aggressively close reports from unsupported package builds.
Filesystem Design, On-Disk Changes, and Upgrades
- bcachefs is described as “a database under the hood,” easing some backward/forward compatibility.
- Two recent impactful on-disk changes are discussed (accounting rewrite, backpointer changes) to improve extensibility and fsck scalability.
- Several commenters like the idea of in-place large metadata/schema upgrades instead of “reformat and restore,” even if they take hours.
Comparisons with Other Filesystems
- Some stick with ext4, XFS, or especially ZFS, citing battle-tested stability and aversion to data-loss risk.
- A data corruption bug in ZFS’s history is noted but argued not to disqualify it from being “rock solid.”
- XFS and ext4 inode behavior and small-file performance are debated; XFS’s dynamic inode allocation is praised, while ext4’s fixed inode count can be a limit in extreme small-file workloads.
Future and Governance Concerns
- A few commenters predict bcachefs could be pulled from mainline if process and interpersonal issues persist with kernel maintainers.
- Others emphasize that current rapid change is part of the experimental phase and appears to be stabilizing.