bcachefs has been in the kernel for three years. Is it your production filesystem yet?

The Linux kernel ships more filesystems than any sane person needs. ext4 for people who want the problem solved and want to sleep at night. XFS for serious throughput. btrfs for people who enjoy debugging their filesystem at 2 AM. OpenZFS for the principled types who have made peace with running a CDDL module outside the kernel tree. f2fs, erofs, nilfs2, a few others for specific niches.

And now bcachefs. Merged into Linux 6.7 in January 2024 after Kent Overstreet spent roughly a decade developing it out-of-tree. It has been accumulating real distribution support and real kernel cycles since then. Three years is enough time to have opinions that are not based on merge announcement press releases.

What problem bcachefs is actually solving

This is worth stating directly because “new filesystem” answers nothing.

bcachefs is not solving the problem ext4 solves. ext4 is a known quantity: POSIX compliant, battle-tested since 2008, metadata journaling that works, fsck that works, nothing surprising ever. If you want your root partition to boot and your data to be where you put it, ext4 is not the problem. It will be supported until long after everyone reading this retires.

bcachefs is solving the problem btrfs was supposed to solve: a copy-on-write filesystem with native checksumming, compression, snapshots, and subvolumes that does not carry a persistent reputation for eating data on RAID configurations. Btrfs has that reputation. It is not entirely fair at this point, but it is not entirely unfair either. The “btrfs RAID5/6 is still not production-ready” caveat sat in the official wiki for years. That kind of thing leaves marks.

Overstreet built bcachefs from the bcache block-layer cache he wrote for the kernel around 2013. The architecture is B-tree top to bottom, which is the right design choice for what he is doing: the B-tree structure handles metadata and extent layout in one place, so checksumming and encryption can be applied at the node level rather than retrofitted on top of something that was not designed for them. btrfs has both checksumming and encryption bolted on in pieces. The bcachefs architecture is cleaner than that.

What it actually does

Native inline encryption, checksumming, compression, snapshots, and subvolumes. Same feature list as btrfs, same as OpenZFS. The differences are implementation depth and whether those features work reliably together when you stress them.

Checksumming is xxHash by default for performance, with crc32c and sha256 as alternatives. Every extent is checksummed. Silent corruption is detectable. On a multi-device configuration, detected corruption triggers automatic repair from the redundant copy. This is the same model ZFS uses and it is the correct model. Silent data corruption is worse than loud data loss because you do not know what you are restoring from.

Compression is LZ4, zstd, or gzip, configurable at the per-file or per-directory level. You can compress cold data and skip compression on hot data with per-directory policies. btrfs supports this too. On btrfs it has historically interacted badly with fragmentation in certain workloads. bcachefs’s B-tree extent layout handles this differently.

The encryption story is where bcachefs has a genuine advantage. It is inline, per-extent, using XChaCha20. Key material lives in the superblock, passphrase provided at mount time. This means you can have encrypted subvolumes without encrypting the whole device. OpenZFS does encryption at the dataset level, which is also real but different. btrfs has no native encryption. You are running dm-crypt underneath it, which means full-device encryption before the filesystem touches anything, with no per-subvolume granularity. bcachefs’s model is more flexible.

Where it is still rough

bcachefs fsck is not ext4 fsck. The tool exists and runs, and for common corruption patterns it does what you need. The recovery paths for serious corruption are less mature than what twenty years of ext4 development produced. If you have a badly corrupted bcachefs volume you want to salvage, you will find the tooling and documentation thinner than you would like.

The on-disk format changed between kernel versions in the first year post-merge. Format stability has improved since then, but anyone who got burned by btrfs format changes will feel the anxiety. It is a valid concern, even if the current situation is better than early btrfs was.

Snapshot deletion performance was an issue in earlier releases. Removing a large number of snapshots ran slowly. This is a classic COW filesystem problem and it has been worked on, but it is worth knowing about before you build a workflow that creates thousands of snapshots.

Production adoption outside the NixOS and container-tooling communities is still limited relative to ext4 or even btrfs. That means fewer users hitting weird edge cases in production and reporting them. The testing surface is narrower than it looks.

The honest comparison

Against ext4: bcachefs is not your rootfs filesystem unless you know what you are doing and have backups you trust. ext4 is still the correct answer for the partition that boots the machine.

Against XFS: different tradeoffs entirely. XFS is for high-throughput workloads with large sequential writes where you do not want COW semantics or snapshots. A busy fileserver with huge files and no snapshot requirement points to XFS. bcachefs is not competing for that workload.

Against btrfs: this is the real fight. bcachefs is doing what btrfs promised, with a cleaner implementation underneath. If you are using btrfs on a desktop or workstation for snapshots and subvolumes without RAID, it probably works fine, but bcachefs on the same workload will likely have fewer surprises over a long period of time. The question is whether “fewer surprises over time” is worth the tooling immaturity right now.

Against OpenZFS: ZFS is more mature, has a larger install base in serious production, has better management tooling at scale (the whole zpool layer, zfs send/recv, scrub, the works), and has fifteen-plus years of FreeBSD deployments behind it. bcachefs is not replacing ZFS for serious storage work in any near-term time frame. The one real advantage bcachefs has is being in the kernel tree, which means no DKMS, no fighting kernel module signing, no version incompatibility on kernel updates. On Linux that matters operationally.

The take

Use ext4 for rootfs. Use OpenZFS if you want serious COW semantics with mature management tooling and you have made peace with the out-of-tree situation. Use bcachefs for secondary volumes where you want COW semantics with native per-extent encryption and you are comfortable with tooling that is genuinely good but not yet great.

Wait another year or two before trusting it with data you cannot afford to lose.

The architecture is sound. Overstreet has been doing kernel work long enough to know what he is doing and the pace of development is real. This is not going to disappear or stall, which was not obvious when it was still sitting out-of-tree with uncertain merge prospects.

Three years in: not ready for your most important data. Not vaporware either. Worth setting up a test volume on something you can afford to blow up.

Check back in 2028.

See also: OpenZFS 3.0 ships RAIDZ expansion and the dedup engine they finally got right for the ZFS side of the storage question, and Linux 7.3-rc1 and where the merge window landed for broader kernel context.