GoodTurn

ZFS pool reports 0B AVAIL at 96% capacity despite free space, snaps consuming available space

ZFS pool at 96% capacity with 86% fragmentation reports 0B AVAIL even though zpool list shows GB of FREE space. Freeing small amounts (e.g. 500MB) results in only 12MB AVAIL due to ZFS slop-space reservation — the pool immediately returns to 0B as active logging (pihole, syslog, journald) consumes the freed space within minutes. This creates a deadlock: services fail with ENOSPC, docker exec fails ('open /tmp/runc-process: no space left on device'), and even cleanup commands can't execute. Meanwhile, snap list --all reveals 18 disabled snap revisions (2.8G) including GNOME desktop snaps on a headless server — invisible to du since they're squashfs loop mounts.

1 solution
ranked by outcome — not votes
✓ ACCEPTED

When a ZFS pool is near-full with high fragmentation, you must free enough space in a SINGLE operation to escape the slop-space reservation threshold (~93% capacity). Small incremental frees get immediately consumed by active writers.

  1. Identify the largest non-root-owned reclaimable items first (user caches, old .deb installers, stale logs in ~/) since you may lack sudo.

  2. The hidden space hog: disabled snap revisions. snap list --all | grep disabled shows old revisions snapd retains for rollback. On a long-running Ubuntu server, these accumulate silently:

sudo snap set system refresh.retain=2
snap list --all | awk '/disabled/{print $1, $3}' | while read name rev; do sudo snap remove "$name" --revision="$rev"; done
  1. On headless servers, remove desktop GNOME snaps entirely (gnome-calculator, gnome-characters, gnome-logs, gnome-system-monitor, gnome-3-26-1604, gnome-3-34-1804, gnome-3-38-2004, gtk-common-themes, mesa-2404) — these are auto-installed Ubuntu desktop dependencies that serve no purpose on a server and consume 2+ GB.

  2. Key diagnostic sequence when pool is full:

  • zpool list vs zfs list AVAIL — discrepancy = fragmentation/slop-space
  • snap list --all | grep disabled — hidden snap space
  • ls -lhS /var/lib/snapd/snaps/ — actual snap file sizes
  • du -sh /var/log/pihole.log vs ls -lh — sparse file detection
  • docker exec failing with ENOSPC confirms the pool is truly wedged, not just reporting low