Is Fedora's Default Btrfs Compression Right for Your Workload?

The problem: space pressure without a clear cause

You provision a Fedora workstation or server, watch the disk fill up, and wonder whether the filesystem is helping or hurting. Since Fedora 33, the installer defaults to Btrfs with transparent zstd compression enabled, but that default is a starting point, not a verdict. The engineering decision is not whether to "turn on" compression—it is already on—but whether the default level fits your data, your CPU budget, and your maintenance window.

What Fedora actually configures

On a fresh Fedora Workstation or Server installation, the root filesystem is Btrfs and new writes are compressed with compress=zstd:1. This level is deliberately conservative: it aims to save space on text-heavy workloads without imposing heavy CPU costs on interactive desktops or general-purpose servers.

The layout also splits the installation into subvolumes for /, /home, and /var. This matters for compression decisions because you can snapshot or roll back a specific path independently, but the mount option applies to the filesystem, not to individual subvolumes. If you change compression, it affects new writes across the mounted subvolumes unless you remount them separately.

Measure the actual ratio before changing anything

Compression ratios depend heavily on file type. Source code, logs, and plain text compress well; JPEG images, video files, and already-compressed archives often show negligible gains. Before adjusting levels, confirm what your data is actually doing.

Start by verifying the mount options on the running system:

findmnt /

Look for compress=zstd in the options list. If it is absent, compression is not active for new writes on that mount.

Next, measure the real-world effect on a specific directory using compsize. This utility reports the actual compression ratio and the space saved by comparing allocated blocks against referenced (logical) blocks:

sudo compsize /home

You can also inspect allocated versus referenced disk usage with:

sudo btrfs filesystem du -s /home

If compsize reports a ratio near 1.00x, your workload is largely incompressible and higher zstd levels will cost CPU without meaningful savings. If the ratio is substantially above 1.00x, you may have room to trade a little more CPU for better density.

When to adjust the compression level

The default zstd:1 is a reasonable middle ground, but it is not universal. On a low-power device—an older laptop or an ARM board—the CPU overhead of higher levels can reduce write throughput enough to matter. On a server with spare cores and a text-heavy workload, a higher level such as zstd:3 may improve density at a cost you will not notice.

Changing the level is not a simple flag flip on existing data. New writes honor the mount option immediately after a remount, but already-written blocks stay at their original compression until you run a balance. A balance rewrites data and is I/O-intensive, so schedule it during a maintenance window.

To change the default for future writes, edit the mount options in /etc/fstab and remount:

sudo mount -o remount /

To apply the new level to existing data, run a balance on the target subvolume or filesystem:

sudo btrfs balance start -dusage=50 /

Adjust the -dusage threshold to control how much data is rewritten. A higher percentage rewrites more blocks and takes longer.

Limitations and trade-offs

• Incompressible data: Media files and archives may not shrink, so compression provides no benefit and still consumes CPU.
• CPU cost: Higher zstd levels increase CPU usage during writes. On low-power hardware, this can reduce throughput.
• Balance cost: Re-compressing existing data requires a balance operation, which is I/O-intensive and can take significant time on large filesystems.
• Snapshots are not backups: Btrfs snapshots share extents and protect against accidental deletion, but they do not protect against filesystem corruption or hardware failure.
• Multi-disk caution: Btrfs RAID5/6 implementations are still considered unstable for production. Use RAID1 or RAID10 for redundancy.

An actionable decision framework

1. Run findmnt / to confirm Btrfs and the current compression option.
2. Run sudo compsize /home (or your largest subvolume) to measure the actual ratio.
3. If the ratio is near 1.0x, keep the default or consider disabling compression to save CPU.
4. If the ratio is high and your hardware has headroom, consider raising the level for new writes.
5. Only run a balance if you need existing data re-compressed, and plan for the I/O cost.

Fedora's default Btrfs compression is a sensible starting point for most installations. The practical decision is not whether to enable it, but whether to measure it, tune it, or leave it alone.