bcachefs is a copy-on-write filesystem for Linux by Kent Overstreet, grown out of the bcache block-layer cache. It aims to combine the feature set of ZFS and Btrfs — checksumming, snapshots, compression, encryption, multi-device replication and erasure coding — with the performance and maintainability of ext4 and XFS. Its stated priority is reliability over speed: "the COW filesystem for Linux that won't eat your data."

Two things changed the picture substantially:

Out of the mainline kernel. After a long-running conflict between Overstreet and the kernel maintainers over the process for merging fixes, bcachefs was marked externally maintained in Linux 6.17 (August 2025) and the code was removed outright in 6.18 (September 2025) — about 117k lines. It now ships out-of-tree as a DKMS module, the same distribution model ZFS uses. The in-kernel code left in 6.17 is stale and should not be used.

No longer experimental. With 1.38.6 (June 2026) upstream dropped the experimental label, on the grounds that incoming bug reports had slowed and become less serious. That is not the same as "production-ready for anything": filesystems earn trust across workloads, hardware and failure modes over years, and the project still advises caution with data you cannot afford to lose. Erasure coding separately became stable in 1.37 (March 2026).

Development is fast — roughly monthly feature releases with point releases in between. As of this writing the current release is 1.39.2 (17 August 2026).

The DKMS module supports Linux 6.16 and newer, tracking new kernels quickly (7.0 support landed in 1.37, 7.2 in 1.38.7).

Packages also exist for NixOS, Gentoo, Void and openSUSE. Since 1.38.7 DKMS can fetch a prebuilt signed module instead of compiling locally, and module signing for Secure Boot is supported; the Rust components build even on kernels without CONFIG_RUST by vendoring the kernel's Rust support tree.

Multi-device with tiering — writes land on the fast device and migrate to the slow one in the background:

Devices are colon-separated at mount time; mounting by filesystem label also works (since 1.38.7). Up to 255 devices per filesystem are supported (raised in 1.38.6). Common format options include --compression, --background_compression, --replicas=N, --encrypted, --data_checksum and per-device --durability and --failure_domain.

All userspace subcommands live under the single bcachefs binary:

Introduced in 1.33 (December 2025) as the successor to rebalance, reconcile is the background engine that makes the rest of the feature set self-managing. It tracks where data is versus where the IO-path options say it should be, and moves it — automatically, without user commands.

It handles all IO-path options rather than just background target and compression, works on metadata as well as user data, and reacts on its own to option changes and device state changes, immediately re-replicating anything degraded. This obsoleted data rereplicate and data job drop_extra_replicas; the interface is now just reconcile status and reconcile wait.

Practical consequence: you can format a single device with replicas=2, add a second device later, and the data replicates itself with no further intervention.

Under the hood there are separate indexes for work that is pending but currently impossible (target full — which fixed long-standing reports of rebalance spinning), and for high priority work such as degraded extents needing re-replication, which jump the queue. Rotational devices are tracked as such and their pending work is additionally indexed in physical LBA order so the mover doesn't seek unnecessarily.

BCH_MEMBER_STATE_failed was renamed evacuating: reconcile automatically drains data off a device in that state. The eventual goal is automatic marking of failing drives from health monitoring — load a server with disks, walk away, come back a year later and swap the dead ones.

Stable since 1.37. It uses Reed-Solomon coding like RAID5/6, but sidesteps the RAID write hole: new data is written replicated first, then converted to stripes in the background, so there is never a window where a stripe is partially updated.

Erasure coding is wired into reconcile, so degraded stripes repair automatically like any other degraded data and stripes can be reshaped. Tiered setups and mixed device sizes work, with the largest possible stripes created. Stripe width is bounded by ec_max_data_blocks and by the number of available failure domains.

New in 1.39.0. Devices can be tagged with the thing that fails together — a shelf, chassis or rack — via the per-device failure_domain option, and replicas are spread across domains rather than merely across devices. This covers data allocation, journal replicas and erasure-coded stripe blocks.

The constraint is hard only for erasure coding, which shortens stripes to the number of domains available. Ordinary replicated allocation will reuse a domain if that is the only way to satisfy the replicas requirement. bcachefs fs failure-domains shows the layout.

Also new in 1.39.0. What was lost is now recorded persistently in a dedicated btree instead of being printed once during fsck and thereafter only recoverable from logs. fsck records inode-scoped damage keyed by bch_sb_error_id, and data lost to device force-removal or read errors is recorded the same way.

bcachefs damage shows what is recorded; it is also exposed via ioctls and debugfs. fsck summarises damaged paths at the end of recovery, resolving them through surviving snapshot versions and naming the parent directory for inodes whose own dirent is gone.

The Principles of Operation (bcachefs-principles-of-operation.pdf, "the PoO") is the reference — 100+ pages as of 1.37, organised into introduction, feature overview and subsystem reference, and steadily absorbing what used to live on the wiki. Development discussion is on lore.kernel.org/linux-bcachefs and IRC; the project is funded through Patreon.