bcachefs: the modern Linux copy-on-write filesystem

The pitch vs other filesystems

Install

# Kernel 6.7+ required (Debian 13 / Ubuntu 24.04+ / Fedora 39+ have it by default)
uname -r           # should be >= 6.7

# Userspace tools
sudo apt install bcachefs-tools
# Or
sudo dnf install bcachefs-tools
sudo pacman -S bcachefs-tools

bcachefs version

Single-disk format

# Wipe the disk first if there's an existing filesystem
sudo wipefs -a /dev/sdb

# Format with bcachefs (compression on, checksumming on by default)
sudo bcachefs format \
    --compression=zstd \
    --discard \
    /dev/sdb

# Mount
sudo mkdir /mnt/data
sudo mount -t bcachefs /dev/sdb /mnt/data

Multi-device + tiered: the killer feature

The most differentiated bcachefs use case: a small fast SSD caching reads / absorbing writes for a much larger HDD pool, presented as one filesystem with all the right semantics.

# Format a tiered FS: NVMe as "promote" cache, HDDs as background
sudo bcachefs format \
    --compression=zstd \
    --label=ssd.cache /dev/nvme0n1 \
    --label=hdd.background /dev/sda \
    --label=hdd.background /dev/sdb \
    --label=hdd.background /dev/sdc \
    --replicas=2 \
    --foreground_target=ssd \
    --promote_target=ssd \
    --background_target=hdd

sudo mount -t bcachefs /dev/nvme0n1:/dev/sda:/dev/sdb:/dev/sdc /mnt/data

Writes hit the SSD first (foreground), then migrate to HDDs in the background; hot reads stay cached on SSD (promote). The filesystem decides per-block where to place data based on access patterns. Comparable to ZFS L2ARC + SLOG but built into the FS instead of bolted on.

Snapshots

# Create a snapshot (snapshots are subvolumes, accessed as a directory)
sudo bcachefs subvolume snapshot /mnt/data /mnt/data/.snapshots/pre-upgrade

# List snapshots / subvolumes
sudo bcachefs subvolume list /mnt/data

# Delete a snapshot
sudo bcachefs subvolume delete /mnt/data/.snapshots/pre-upgrade

# Read-only snapshots
sudo bcachefs subvolume snapshot --readonly /mnt/data /mnt/data/.snapshots/locked

Snapshots are O(1) at creation time + use only the storage needed for diverging blocks. Useful for "snapshot before risky operation; roll back if it goes wrong."

Per-file / per-directory properties

# Set compression for a specific directory
sudo bcachefs setattr --compression=zstd /mnt/data/logs/

# Disable compression for already-compressed content
sudo bcachefs setattr --compression=none /mnt/data/photos/

# Force a directory's data to live on the SSD only (hot tier)
sudo bcachefs setattr --background_target=ssd /mnt/data/index/

# View current attrs
sudo bcachefs getattr /mnt/data/logs/

Encryption

# Format with encryption (prompts for passphrase)
sudo bcachefs format --encrypted /dev/sdb

# Unlock + mount
sudo bcachefs unlock /dev/sdb     # prompts for passphrase
sudo mount -t bcachefs /dev/sdb /mnt/data

Per-extent encryption; the on-disk metadata is encrypted too. Pair with Tang + Clevis (see that tutorial) for network-bound auto-unlock.

Health + scrubbing

# Per-filesystem health
sudo bcachefs fs usage /mnt/data
sudo bcachefs show-super /dev/sdb

# Scrub (verify checksums + scan for bit-rot)
sudo bcachefs data scrub /mnt/data

bcachefs continuously verifies checksums on read; a scheduled scrub catches bitrot in cold data that hasn't been read recently. Run weekly via systemd timer (see that tutorial).

Stability picture in 2026

bcachefs has had a turbulent run in mainline Linux. Kernel 6.7-6.8 carried the initial merge; 6.9-6.13 saw active stabilization + bugfixes; the relationship between Kent Overstreet (developer) and Linux mainline became publicly strained, leading to questions about long-term in-kernel status. As of 2026:

• The filesystem itself works for many users; people run it on home backup boxes, large photo libraries, etc.
• It is still marked experimental in the kernel.
• The userspace tooling (bcachefs-tools) lags behind kernel features sometimes.
• Recovery from corruption is more complex than ext4/xfs — familiarize yourself with fsck before you need it.
• Watch the kernel news for upstream status changes.

When bcachefs is interesting

• You have one or two SSDs + many HDDs and want tiered storage as one filesystem (without ZFS's separate L2ARC complexity or having to keep the metadata DDT in RAM).
• You're a curious homelab user willing to operate experimental tech for the operational learning.
• You want CoW + snapshots + compression + checksums but ZFS's non-kernel-mainline situation is a blocker.

When it isn't

• For "I want this to never lose my data," ZFS (see that tutorial) has 20 years of production hardening. bcachefs has under 5.
• For root filesystems where boot resilience matters, ext4 + LVM (see that tutorial) is the boring + safe choice.
• For workloads needing maximum performance on a single fast SSD, plain ext4 or xfs typically win on raw IOPS.

Worth knowing

• Replication. --replicas=N at format means N copies of data + metadata across the device set. Survives N-1 device failures.
• Erasure coding. bcachefs supports per-extent erasure coding (smarter than RAID-5/6 + CoW); availability is improving.
• Device add / remove on a mounted FS. Add a new disk to a running bcachefs, rebalance happens in background; remove via similar workflow. Comparable to ZFS device expansion (which only landed in OpenZFS 2.3).