Why Fedora’s Default Btrfs Matters: Snapshots, Compression, and Real‑World Trade‑offs

Why the Default Filesystem Matters

When you install Fedora 40, the installer mounts / and /home on Btrfs instead of Ext4. At first glance this feels like a cosmetic change, but the engineering decisions behind that choice ripple through every backup, upgrade, and recovery operation. The core benefits are instant snapshots, transparent compression, and subvolume isolation. The flip side is fragmentation on certain workloads and a subtle shift in how you interpret disk usage.

Subvolumes: The Building Blocks of Isolation

Btrfs introduces the concept of subvolumes, logical partitions that live on the same physical device. The Fedora installer creates two top‑level subvolumes:

• @ – the root filesystem (/)
• @home – the user data directory (/home)

This separation lets you snapshot / without touching /home, and vice‑versa. It also means you can roll back the system itself without wiping user data, a huge win for developers and sysadmins.

Verify the hierarchy with:
sudo btrfs subvolume list /

Copy‑On‑Write: Snapshots in a Snap

Copy‑On‑Write (CoW) is the magic behind instant snapshots. When you run:

sudo btrfs subvolume snapshot -r / @snap_20261009

Btrfs copies only the metadata; data blocks remain shared until they are modified. The snapshot appears as a new read‑only subvolume, but it consumes virtually no space at creation time. Only subsequent changes to the original data will duplicate blocks, which is why snapshots are so fast.

To test the space impact, run:

df -h / | grep 'Used'

Immediately after the snapshot, the “Used” column should be unchanged. After you modify a file in /, the snapshot will start to consume space, reflecting the new copies.

Transparent Compression: zstd Saves Space and I/O

Fedora mounts Btrfs with compress=zstd by default. Zstd offers a good balance between compression ratio and CPU overhead. The filesystem automatically compresses new data blocks, which reduces disk I/O and effectively increases available storage.

Check the compression mode:

sudo btrfs filesystem df / | grep 'Compression'

You should see a line like Compression: zstd. To confirm that data is actually compressed, inspect a file with lsblk -f or use btrfs filesystem usage.

When CoW Turns into Fragmentation

CoW works great for typical user workloads, but it can bloat on files that change frequently in small chunks—think database logs or virtual machine images. Each small write can create a new block copy, leading to fragmentation and degraded performance.

Mitigation: set the nodatacow attribute on directories that host such workloads:

sudo chattr +C /var/lib/libvirt/images

This tells Btrfs to write data normally (no CoW) for that directory, preserving performance at the cost of snapshotability.

Disk Space Reporting: A Different Lens

Because Btrfs shares blocks between subvolumes and snapshots, the df output can be misleading. The “Available” column may appear higher than it actually is because it counts shared blocks only once. Use btrfs filesystem usage / to get a more accurate picture of how much space is truly consumed.

Snapshots Are Not Backups

While snapshots are great for quick rollbacks, they live on the same physical device as the data they protect. A catastrophic failure (disk crash, accidental deletion) will wipe both the original and all snapshots. Always pair snapshots with external backups.

Practical Example: Rolling Back to a Previous State

1. Take a read‑only snapshot of the root:

   sudo btrfs subvolume snapshot -r / @snap_before_update
   

2. Perform a risky system update.
3. If the update breaks something, reboot into the snapshot by editing the GRUB entry.

   sudo grub2-mkconfig -o /boot/grub2/grub.cfg
   

   Add a new menu entry pointing to the snapshot’s subvolume ID (visible via sudo btrfs subvolume list /). Boot, and you’ll have a pristine system state.

Trade‑offs and Takeaway

• Pros: instant snapshots, reduced storage footprints via compression, isolated subvolumes.
• Cons: fragmentation on heavy write workloads, space reporting quirks, snapshots not a backup.

For most Fedora users, the default Btrfs setup offers a powerful, low‑overhead way to manage system state. If you run databases or VMs, be proactive about nodatacow and external backups.

Actionable Checklist

• Verify the filesystem: sudo btrfs filesystem show
• Inspect subvolumes: sudo btrfs subvolume list /
• Test a snapshot: sudo btrfs subvolume snapshot -r / @test_snap
• Check compression: sudo btrfs filesystem df / | grep Compression
• Set nodatacow on write‑heavy directories.
• Schedule external backups; treat snapshots as a safety net, not a replacement.

With these steps, you’ll harness Fedora’s Btrfs features effectively while staying aware of its limits.