BCacheFS is being disabled in the openSUSE kernels 6.17+

Original Article ↗ Hacker News Discussion ↗

Decision to disable BCacheFS in openSUSE

  • Many see disabling BCacheFS in openSUSE 6.17+ as “inevitable” given upstream drama and process issues, though others describe it as a tragedy given the filesystem’s promise.
  • Some users had already migrated away from BCacheFS on openSUSE, anticipating this outcome.
  • Several hope it will stabilize out-of-tree and eventually be re-merged once it’s low-drama and small-change.

Kernel process, behavior, and drama

  • A major theme is conflict between the BCacheFS maintainer and kernel processes: alleged repeated attempts to push new, insufficiently tested features into release-candidate bugfix windows, breaking builds, and arguing instead of working through reviews.
  • Others contest or question these accounts, saying the stories get exaggerated.
  • The “behaves” wording from an openSUSE maintainer email is debated; it was later apologized for as non-native phrasing, and the decision to disable was partially walked back after direct discussion.
  • Some frame this as CoC/politics and “piling on,” others as a straightforward enforcement of long-standing kernel rules.
  • There’s a philosophical clash: one side stresses being effective in a large project even if you disagree; the BCacheFS maintainer counters that technical correctness and strong leadership matter more than popularity.

Future of BCacheFS

  • BCacheFS is not dead: development continues out of tree; people are working on DKMS packages and some distros have reconsidered disabling it.
  • A few report using it successfully (e.g., SSD+HDD tiering) and praise its design and data-integrity focus, while treating it as experimental.
  • Concern remains that future attempts to re-merge could still hit friction if they modify non-filesystem subsystems (e.g., block I/O, locking).

Btrfs vs ZFS vs others

  • Strong disagreement over Btrfs:
    • One camp claims “data-eating” bugs are historical FUD and that Btrfs has been reliable for years if used sanely (and not with RAID5).
    • Another camp presents multiple recent anecdotes of corruption, unmountable filesystems, broken discard/quotas, and painful recovery, and criticizes developer responsiveness.
  • BCacheFS is often contrasted as a cleaner design that openly embraced “experimental” status and prioritized integrity tooling, but is still not fully trustable.
  • ZFS is praised for robustness and features (compression, snapshots), but also described as complex, easy to misconfigure, and missing or breaking some Linux-specific integrations; people warn it’s not a magic bullet either.

ZFS on Linux and kernel evolution

  • Some fear upcoming kernel changes (e.g., write-cache-page handling in 6.18) will make ZFS on Linux harder to maintain, leaving no fully satisfying alternative (Btrfs distrusted, BCacheFS out, LVM-thin considered dangerous).
  • Others note ongoing work like “AnyRaid” in ZFS to address drive-size/geometry constraints.

Technical side-notes

  • CoW performance: commenters say all CoW filesystems trade speed for features; the BCacheFS maintainer argues most overhead now comes from rich metadata, accounting, and self-healing, not CoW itself.
  • There is side discussion of:
    • Overlay/caching stacks (bcache, mergerfs) and their limitations.
    • Filesystems-in-userspace (FUSE, microkernels, Redox OS) and how modern hardware makes context-switch costs less prohibitive.