Don’t Trust `df` on ZFS and Btrfs: Where Did My Space Go?

Technical Briefing | 10/19/2026

You’ve been there: `df -h` shows plenty of free space, but your `zfs send` or `btrfs receive` is failing with ‘no space left on device’. Or maybe you’re just scratching your head wondering why a 100GB dataset still eats up 80GB after you’ve deleted half its files. It’s not a bug, and your eyes aren’t playing tricks on you. What you’re seeing is a fundamental misunderstanding of how copy-on-write (CoW) filesystems report disk usage, and it’s something that’s bitten almost everyone working with ZFS or Btrfs in production.

The `df` Illusion: Snapshots, Blocks, and Shared Pain

Traditional filesystems, even those with snapshots via LVM, operate on a simpler block allocation model that `df` understands fairly well. If you delete a file, its blocks are marked free, and `df` reports that space back to you. But ZFS and Btrfs are different animals entirely. They’re copy-on-write. When you create a snapshot, it’s not a separate copy of data. Instead, the filesystem stops modifying existing blocks for files that existed at the time of the snapshot. Any writes to those files now get new blocks, leaving the old, unchanged blocks associated with the snapshot. This means blocks are often *shared* between the live filesystem and its snapshots. And `df` just can’t see that complexity.

The problem compounds quickly. If you have a dataset with a handful of old snapshots, deleting a file from the *live* filesystem might not free up any blocks at all if that file still exists in *any* active snapshot. `df` will report less space used because the live filesystem no longer references the file, but the physical blocks are very much still in use by the snapshots. This silent consumption of space can sneak up on you, especially when you’re relying on automated cleanup that only targets the ‘visible’ data. I’ve personally seen this lead to critical production systems hitting read-only states because the underlying pool ran completely out of space, despite `df` on the dataset showing room to spare.

zfs list -o space -t filesystem,volume,snapshot
btrfs filesystem usage /mnt/btrfs_pool
btrfs subvolume list -o -t /mnt/btrfs_pool

Reclaiming Space: The Snapshot Dance

The bottom line is this: to truly reclaim space on ZFS or Btrfs, you usually need to delete snapshots. Simply deleting files from the active filesystem often won’t cut it. Each snapshot holds onto its unique blocks and any blocks shared only with *it*. Once the last snapshot referencing a block is gone, *then* that block becomes truly free. This is why a rigorous snapshot retention policy isn’t just good practice for data recovery, it’s absolutely essential for managing disk space effectively. Otherwise, you’re just stacking up old versions of data, blissfully unaware of the underlying block usage.

• Regularly review your snapshot retention policies; automate deletion of older, less critical snapshots.
• Understand `zfs destroy` and `btrfs subvolume delete`. Know that a recursive `zfs destroy` on a dataset *will* delete its child snapshots, which is often what you want for full space reclamation.
• Monitor physical pool usage with `zpool list` (ZFS) or `btrfs filesystem usage` (Btrfs) directly, not just `df` on individual mount points.
• Be wary of long-lived or many ‘read-only’ snapshots that are never rotated; they’re silently accumulating unique block usage.

Managing space on CoW filesystems isn’t just about deleting files; it’s about understanding block sharing and managing your snapshot lifecycle. Ignoring this nuance means you’re going to hit ‘no space’ errors at the worst possible time, I guarantee it. Get comfortable with `zfs list -o space` and `btrfs filesystem usage` now, and make snapshot retention a first-class citizen in your storage strategy. Your future self will thank you for it when that critical `zfs send` actually completes.