bcachefs

A Filesystem Worth Taking Seriously, and a Situation Worth Understanding

Most Linux users reach for ext4 because it works. Some graduate to
Btrfs for snapshots or ZFS for its data-integrity guarantees. There
is a third serious contender in the copy-on-write filesystem space
that most people have never run, and its story in 2026 is the most
interesting in Linux storage: bcachefs, a filesystem whose technical
design is arguably the best of the three and whose relationship with
the kernel community collapsed so completely that it was removed
from the kernel tree entirely.

Both of these things are true at once, and holding them together is
the only honest way to write about bcachefs. The engineering is
genuinely excellent. The governance situation is genuinely a
problem. An operator deciding whether to run bcachefs has to weigh
the first against the second, and most of the writing on the topic
picks one and ignores the other. This post tries to do neither.

Where It Came From

bcachefs grew out of bcache, the Linux block-layer cache that Kent
Overstreet wrote to put an SSD in front of spinning disks. The
insight that turned a cache into a filesystem was that the b-tree
data structure bcache used for indexing was fast enough and general
enough to underpin an entire POSIX filesystem. Overstreet left
Google to work on it full time, announced bcachefs in 2015 as
roughly feature-complete, spent years funded partly through Patreon
refining the on-disk format, and finally landed it in the mainline
kernel with Linux 6.7 in January 2024.

The b-tree at the heart of it is the part worth understanding,
because it is the source of both the performance and the
credibility. The nodes are log-structured, and the in-node search
uses an Eytzinger layout, which stores the keys in an order
optimized for the CPU cache rather than in sorted order, eliminating
the cache misses that a conventional binary search incurs. Overstreet
has described it as the fastest ordered, persistent,
production-quality key-value store in existence, and independent
benchmarks have not embarrassed the claim. The filesystem is built
on top of this key-value store, which is an unusually clean
architecture: the hard problems of ordering, persistence, and
lookup are solved once, in the b-tree, and the filesystem is a
consumer of that solution.

What It Actually Does

The feature set is the reason bcachefs was positioned as a
competitor to ZFS and Btrfs rather than to ext4. Everything you
would expect from a modern copy-on-write filesystem is present, and
several things are done better than the incumbents do them.

Copy-on-write means data is never overwritten in place. A
modification writes the new state to a new location and updates the
pointer, which is the foundation for snapshots, for data integrity,
and for the absence of the write-hole that plagues traditional RAID.

Full data and metadata checksumming, with CRC-32C and 64-bit CRC
options, means corruption is detected rather than silently served.
This is the ZFS property that made ZFS worth its complexity, and
bcachefs has it natively.

Native encryption uses ChaCha20 for the cipher and Poly1305 for
authentication, which is both a modern choice and a properly
authenticated one, meaning the encryption detects tampering rather
than merely obscuring data. This is cleaner than the LUKS-underneath
arrangement that most Linux full-disk encryption uses, because the
filesystem and the encryption are aware of each other.

Compression is available through LZ4, gzip, and zstd, selectable per
filesystem and changeable after creation.

Multi-device support with replication lets the filesystem span
several disks with configurable numbers of replicas, which is RAID
functionality implemented inside the filesystem where it can be
aware of what it is protecting.

Native tiered storage is the feature that betrays bcachefs's origin
as a cache. The filesystem can use fast disks (SSD, NVMe) as a tier
in front of slow disks (spinning rust), promoting hot data to the
fast tier and demoting cold data to the slow one, automatically,
inside the filesystem. ZFS approximates this with its L2ARC and SLOG
arrangements, but bcachefs does it as a first-class design feature
because caching is literally what the codebase was born to do.

The Erasure Coding Argument

The feature worth singling out, because it is where bcachefs's
design is genuinely better rather than merely competitive, is
erasure coding. Erasure coding is the general form of parity RAID:
it stores data across devices with computed redundancy so that the
loss of a device can be recovered from the parity, at a fraction of
the storage cost of full replication.

Every parity RAID implementation has to contend with the write hole.
If a stripe is partially updated when the system loses power, the
data and the parity can disagree, and the corruption is silent.
Traditional RAID handles this with a journal or a battery-backed
cache. Btrfs's parity RAID is still affected by the write hole,
which is why its RAID5 and RAID6 modes have carried stability
warnings for years. ZFS avoids the write hole by turning every write
into a full new stripe, which works but fragments every write across
every disk in the set, and on spinning disks that fragmentation is a
serious performance cost because read performance is dominated by
seek time and a fragmented read means many seeks instead of one.

bcachefs takes a different route that follows directly from it being
copy-on-write to begin with. It never updates existing stripes in
place. Foreground writes are initially replicated, and when a stripe
is complete the parity blocks are computed and the extra replicas
dropped, with the stripe never overwritten until it is empty and
released. The result is no write hole, no data fragmentation, and a
data layout identical to what it would be with no redundancy at all.
This is the cleanest erasure coding design of the three filesystems,
and it is the reason a specific kind of storage engineer has been
watching bcachefs closely: it is the ZFS data-integrity story
without the ZFS fragmentation cost and without the Btrfs write hole.

The Situation

Everything above is the case for bcachefs. Here is the case against,
and it is not technical.

In June 2025, Linus Torvalds announced that bcachefs would be
parting ways with the kernel in the 6.17 merge window. The dispute
was about development process. Overstreet had repeatedly submitted
substantial changes, not just bug fixes, late in the release cycle,
during the release candidates, which is precisely when the kernel is
supposed to be stabilizing rather than taking new features. The
breaking point was a large patch called journal_rewind submitted
late in the 6.16/6.17 cycle. Torvalds's position, in his own words,
was that he had been told he could not even question the bug fixes
and should pull anything and everything, and that he did not feel
comfortable being involved on those terms. The one thing both
parties agreed on in that exchange was that they were done.

The mechanics followed quickly. In August 2025 the MAINTAINERS file
changed bcachefs's status from "Supported" to "Externally
maintained," which meant the in-kernel code stopped receiving
updates. In the 6.18 cycle the code was removed entirely, roughly a
hundred and seventeen thousand lines, on the reasoning that the
in-tree copy had gone stale relative to the external development and
would only cause version confusion. bcachefs now ships as a DKMS
module, exactly like OpenZFS, compiled against the running kernel
out of tree, distributed through a dedicated APT repository at
apt.bcachefs.org and through first-tier packaging on Arch and NixOS.

The context that matters is that this was not purely a technical
disagreement. Overstreet had been restricted by the kernel's Code of
Conduct Committee during the 6.13 cycle over conduct toward another
community member. The friction was not only about merge windows. It
was about whether one developer's working style could coexist with
the kernel's process norms, and the answer the kernel arrived at was
that it could not.

What This Means for Running It

The DKMS transition is the practical consequence an operator has to
plan around, and it is worth being clear-eyed about what it costs.

The upside is real. Freed from the kernel's merge cadence, bcachefs
can ship fixes on its own schedule, and in June 2026 the project
dropped the "experimental" label with tools version 1.38.6, with
Phoronix benchmarks showing the DKMS version performing as well or
better than the in-tree version had. Development standards, according
to Overstreet, remain high, and the focus is on closing out the
remaining bugs. The filesystem is more usable now, by its own
maturity marker, than it was while it was in the kernel.

The downside is the downside of every out-of-tree kernel module, and
ZFS users have lived it for years. The module has to build against
every kernel you upgrade to. When the kernel changes an internal API,
the module can break until it is updated, and you can be left unable
to boot if the filesystem holding your root is served by a module
that will not compile against your new kernel. The initramfs has to
include the module. Distributions that refuse to ship out-of-tree
modules on policy grounds will not carry it, pushing you to community
repositories. For a root filesystem, this is a real operational
commitment, not a casual one.

The comparison with ZFS is the right frame, because ZFS is the
filesystem that has run as an out-of-tree DKMS module on Linux for
its entire existence and has done so successfully in serious
production. The DKMS model is not disqualifying. ZFS proves that a
well-maintained out-of-tree filesystem module can be depended on.
What ZFS also demonstrates is the cost: the kernel-upgrade dance, the
occasional module-build failure, the need to keep the module and the
kernel in a compatible relationship, the lag between a new kernel
release and the module supporting it. bcachefs is now signed up for
the same arrangement, with a smaller community and a shorter track
record behind it.

The Honest Recommendation

For a production system where uptime and recoverability are the
priority, bcachefs is not yet the choice I would make. Not because
the design is wrong, but because the combination of a recently
dropped experimental label, an out-of-tree distribution model with a
short track record, and a governance situation that cost it the
kernel's institutional support adds up to more risk than a
production root filesystem should carry. ZFS for data integrity on a
NAS, or plain ext4 or XFS for a root filesystem that just needs to
work, remain the conservative and correct choices for systems that
matter.

For a homelab, a test machine, a secondary data volume with good
backups, or any environment where the operator wants to understand
the filesystem that a serious fraction of storage engineering will
be arguing about for the next decade, bcachefs is worth running now.
The tiered storage is genuinely useful for a mixed SSD-and-HDD
homelab. The erasure coding is genuinely better than the
alternatives. And the experience of running it teaches you the
design that the other filesystems will be measured against, whether
or not bcachefs itself wins.

The one firm rule, which applies to any copy-on-write filesystem and
doubly to one this young: have backups that do not live on the
filesystem you are testing. The three-independent-layers backup
discipline I have written about applies with full force here. A
filesystem you are running specifically because it is new and
interesting is a filesystem you should assume can eat your data, and
the assumption should be backed by a restore path that does not
depend on it.

Closing

bcachefs is the clearest case I know of a project where the
engineering and the politics point in opposite directions. The
b-tree architecture is elegant. The erasure coding design is the
best of the three major copy-on-write filesystems. The tiered
storage is a first-class feature that the competitors approximate.
On pure technical merit, bcachefs is the most interesting filesystem
to arrive on Linux in a decade.

And it is out of the kernel, because the person who wrote that
elegant architecture could not work within the process norms of the
project he wanted it merged into. The kernel is a collaborative
system with rules about how changes land, and those rules exist
because a hundred thousand lines of filesystem code in the tree that
millions of people boot cannot be a single developer's sandbox. The
removal was a governance decision, not a technical judgment, and the
technical excellence of the code did not save it, because technical
excellence was never the thing in dispute.

For the operator, the lesson is to separate the two evaluations. The
filesystem is good. The distribution situation is a real cost. Run
it where the cost is acceptable, which is the homelab and the test
bench and the well-backed-up secondary volume, and watch what
happens to it over the next few years. Whether bcachefs recovers the
kernel's trust or remains a permanent out-of-tree project like ZFS,
the design is worth knowing, and the story is worth understanding as
a case study in how the best code does not automatically win when it
arrives attached to a process the community cannot absorb.