Disk Usage Analysis

Monitoring and Performance covers df -h as part of a general system health check. This goes a level deeper: once df says a filesystem is nearly full, these are the tools for finding out exactly what's responsible.

Start at the filesystem level

df -h

Confirms which filesystem is full and by how much - the first question, since /, /var, and /home might be separate mounts (see Mounting and fstab), and filling one doesn't affect the others.

du: directory-level usage

du -sh /var/log/*              # total size of each item, one line each
du -sh /var/log/* | sort -rh | head -10   # the 10 biggest, sorted
du -h --max-depth=1 /var       # one level of subdirectories, human-readable sizes

du walks the actual directory tree and adds up file sizes - slower than df (which just asks the filesystem for its own summary), but tells you where the space went rather than just that it's gone.

ncdu: the interactive version

ncdu /var

Not installed by default on most distros, but worth adding: ncdu scans a directory once and then lets you navigate the results interactively - drilling into subdirectories, sorted largest-first, without re-running du at every level. The practical tool of choice once a du one-liner isn't narrowing things down fast enough.

Finding specific large or old files

find / -xdev -size +500M                    # files over 500MB, current filesystem only
find /var/log -mtime +90 -name "*.log"       # log files untouched in 90+ days

-xdev keeps find from crossing into other mounted filesystems (like a network share under /mnt), which both speeds up the search and keeps results relevant to the filesystem that's actually full.

When df and du don't agree: the deleted-but-open file

A specific, confusing failure mode: df reports a filesystem as nearly full, but du -sh / on the whole tree adds up to far less than that. The usual cause is a file that was deleted but is still open by a running process - deleting a file only removes its directory entry; the disk space isn't actually released until every process with it open closes it. A runaway log file deleted without restarting the service writing to it is the classic case: the space doesn't come back until that process stops or is restarted.

sudo lsof +L1

Lists open files with a link count of less than 1 - i.e. deleted but still held open - along with the process holding them and how much space each is using. Restarting (or signaling, see Signals) that process releases the space immediately.

Inodes: a separate resource from space

A filesystem can run out of inodes (the fixed-size table entries that track files and their metadata) while still showing plenty of free space - typically from an application creating huge numbers of tiny files, like a cache or session store that's never pruned:

df -i

Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/sda2      15728640 15728640      0  100% /

IUse% 100% with df -h still showing free space is the signature of this specific problem - the fix is deleting files (any files, even tiny ones), not freeing up bytes.