Btrfs on New Disks: When to Use It

Updated 14 November 2026 · Standard formula, shown below

Yes, you should use Btrfs on newly installed disks if you want snapshotting, checksumming, and flexible subvolumes, but only if you understand its trade-offs in performance and complexity. For a single-disk desktop or laptop, Btrfs is a solid choice; for a busy database server, ext4 or XFS may still be better. This article explains what Btrfs does, where it shines, where it struggles, and how to decide for your specific workload.

What Btrfs Actually Is

Btrfs (often pronounced “butter FS” or “bee-tree FS”) is a copy-on-write (CoW) filesystem for Linux, developed since 2007 and considered stable for general use since around 2014. It was designed to address limitations of older filesystems like ext4 by integrating features that usually require separate tools or layers:

Snapshots – instant, space-efficient point-in-time copies of the entire filesystem or a subvolume.
Checksumming – every data block gets a checksum, so silent corruption (bit rot) can be detected and, if you have redundancy, repaired.
Subvolumes – independent, named trees within one filesystem, each with its own snapshot and mount options.
Compression – transparent zstd, lzo, or zlib compression at the filesystem level.
RAID support – native RAID 0, 1, 10, and (experimental) 5/6, with the ability to add or remove devices online.
Send/receive – efficient incremental backup streams.

Unlike ZFS, Btrfs is included in the mainline Linux kernel, so it works on any distribution without extra modules or licensing concerns (it’s GPL). It also supports online defragmentation and online filesystem growth/shrink.

How Btrfs Works: CoW, Subvolumes, and Checksums

The core idea is copy-on-write: when you modify a file, Btrfs doesn’t overwrite the old data in place; it writes new data to a new location and updates a metadata pointer. This is what makes snapshots cheap – a snapshot just copies the metadata, not the data. It also means that a crash during a write won’t leave a partially overwritten file; you get either the old or the new version.

Subvolumes are like separate filesystems sharing the same pool of space. You can create a subvolume for /, one for /home, one for /var/lib/docker, and snapshot each independently. This is how tools like Snapper (used by openSUSE and some Arch setups) provide system rollback: they snapshot the root subvolume before every package transaction, and you can boot into an old snapshot if an update breaks something.

Checksums are stored in metadata for every data block (typically 4 KiB). When reading a file, Btrfs verifies the checksum. If it doesn’t match, the filesystem returns an error and, if a redundant copy exists (e.g., on a RAID1 pair), it automatically repairs the bad block. On a single disk, it can only detect corruption, not fix it, but detection is still valuable – you’ll know a file is bad before you back it up.

When Btrfs Is a Great Choice

For many modern use cases, Btrfs is the best default:

Desktop and laptop – snapshots for system updates, easy rollback, and compression saving disk space (especially on SSDs).
Home NAS or media server – RAID1 for two disks, checksums to protect photos and documents, and send/receive for offsite backups.
Virtualization – storing VM images with CoW can be efficient if you take snapshots, but be aware of fragmentation (see below).
Docker and containers – overlay2 storage driver works well on Btrfs, and subvolumes can be used for per-container quotas.

Distributions like openSUSE and Fedora use Btrfs as the default root filesystem, which means it’s been tested by millions of users. For a typical single-disk Linux install, Btrfs with zstd compression often gives you more usable space and better snapshot capabilities than ext4, with a small CPU cost.

When to Avoid Btrfs

There are scenarios where Btrfs is not the best choice:

Heavy database workloads – PostgreSQL, MySQL, or SQLite on a busy server. CoW causes write amplification and fragmentation; you can disable CoW per file with chattr +C, but then you lose checksumming for those files. ext4 or XFS are generally faster for transactional workloads.
RAID 5/6 – still not recommended for production due to known write-hole issues. Use RAID1 or RAID10, or use mdadm/LVM for parity RAID.
Very small disks (e.g., 16 GB SD cards) – Btrfs metadata overhead is higher than ext4; you’ll lose more space to internal structures.
If you need maximum raw performance – in many benchmarks, ext4 and XFS outperform Btrfs for simple sequential reads/writes, though the gap has narrowed with recent kernels.

Also note that Btrfs does not support certain features that other filesystems have, like online filesystem check (fsck) that runs while the filesystem is mounted. You can run btrfs check only on an unmounted filesystem, and it’s a slow, memory-hungry process.

Common Problems and Misconceptions

One frequent misconception is that Btrfs is “unstable” or “experimental.” While early years were rough, the core features (snapshots, subvolumes, checksums, RAID1) are reliable for everyday use. However, you should still avoid RAID 5/6 and be cautious with some advanced features like deduplication (which is not yet fully integrated).

Another issue is fragmentation on CoW filesystems, especially for large files that are frequently written in small chunks (like VM images or database files). This can lead to high fragmentation and reduced performance. You can mitigate with defrag (though it breaks reflinks and snapshots) or by using the noCOW attribute for files that don’t need snapshots.

Also, ENOSPC (out of space) errors can occur even when df shows free space, because Btrfs reserves space for metadata and for ongoing snapshots. The filesystem can get into a state where it can’t allocate new blocks for metadata, even though data blocks are free. This is less common now, but you should monitor space usage with btrfs filesystem usage rather than just df.

How to Set Up Btrfs on a New Disk

If you decide to go with Btrfs, here’s a typical setup on a fresh disk using the command line (assuming you have a partition, e.g., /dev/sda1):

Create the filesystem: mkfs.btrfs -L mydata /dev/sda1 (add -m single -d single for a single disk, or -m raid1 -d raid1 for two disks).
Mount it: mount /dev/sda1 /mnt
Create subvolumes: btrfs subvolume create /mnt/@ and btrfs subvolume create /mnt/@home (common naming).
Add mount options to /etc/fstab: subvol=@ for root, subvol=@home for home, plus options like compress=zstd, noatime.
Enable snapshots with a tool like Snapper or create manual snapshots: btrfs subvolume snapshot / /mnt/@snapshots/2024-01-01

If you’re using a distribution installer (like Fedora or openSUSE), it will set this up for you automatically. For a data disk, you can simply format it as Btrfs and use it without subvolumes.

Btrfs vs. ext4 vs. XFS vs. ZFS

Here’s a quick comparison to help you choose:

ext4 – the safe, mature choice. No snapshots, no checksums, but rock-solid and fastest for many workloads. Good for simple data disks where you don’t need advanced features.
XFS – excellent for large files and high-throughput servers, but no snapshots or checksums (unless you use LVM or dm-integrity). Good for media storage.
ZFS – the most feature-rich (snapshots, checksums, RAID-Z, deduplication) but not in the mainline kernel (usually via DKMS or OpenZFS). Uses more RAM and has licensing issues. Good for large NAS setups.
Btrfs – the middle ground: most ZFS-like features, in the kernel, but with some rough edges. Good for most Linux users.

For a single-disk desktop, Btrfs gives you more than ext4 with little downside. For a multi-disk NAS with heavy data protection needs, ZFS might be better. For a high-performance database server, XFS or ext4 with LVM snapshots might be safer.

Frequently Asked Questions

Is Btrfs safe for production use?

Yes, for standard features like snapshots, subvolumes, and RAID1, Btrfs is considered stable and is the default on major distributions. However, you should avoid RAID 5/6 and treat them as experimental. Also, always keep backups – no filesystem can protect against hardware failure or user error.

Does Btrfs slow down my system?

There is a small CPU overhead for checksumming and compression, but on modern hardware it’s usually negligible. With zstd compression, you may actually see faster reads because less data is read from disk. For write-heavy workloads, you might notice a slowdown compared to ext4, especially with many small writes.

Can I convert my existing ext4 disk to Btrfs?

Yes, there is a btrfs-convert tool that can convert an ext4 filesystem to Btrfs in-place. However, the process is risky and not recommended for production data. It’s better to back up, format as Btrfs, and restore. Also, the converted filesystem may not have optimal layout.

How do I recover a file from a Btrfs snapshot?

If you have a snapshot, you can simply browse it as a read-only directory (e.g., /mnt/@snapshots/2024-01-01) and copy the file back to its original location. If you don’t have a snapshot, recovery is difficult because Btrfs doesn’t have a traditional undelete tool; you might need to use btrfs restore on an unmounted filesystem, but it’s not guaranteed.

Does Btrfs work on SSDs?

Yes, Btrfs works well on SSDs. It supports TRIM (discard) automatically if you mount with discard or run fstrim. CoW can cause extra write amplification, but with modern SSDs that have good endurance, it’s rarely a concern. You can also use the ssd mount option to optimize allocation for SSDs.

Can I use Btrfs for the root filesystem?

Absolutely. Fedora and openSUSE do it by default. You’ll need to set up subvolumes for / and /home (and possibly /var or /tmp) to make snapshots and rollback work cleanly. The distribution installer will handle this for you.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.