Inspecting Disk Usage

Two commands answer what sounds like the same question — “how much space is being used” — but they’re actually answering it from two different directions, and the gap between them is exactly where a genuinely confusing real-world problem tends to show up. This chapter covers both, and that gap specifically.

df: Disk Free, At The Filesystem Level

df reports space usage per mounted filesystem — the big picture, one line per mount point.

df -h

-h — human-readable, the same convention from ls -lh — shows sizes as 4.2G or 512M rather than a raw byte count that takes real effort to parse at a glance.

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        98G   42G   51G  46% /
/dev/data_vg-data_lv  15G  8.2G  6.1G  58% /mnt/data

Every row here corresponds to a mounted filesystem from the Mounting chapter — including, as you can see, an LVM logical volume, listed exactly like any other mounted filesystem. Add -T to also show each filesystem’s type, tying directly back to the Filesystems chapter:

df -hT

du: Disk Usage, At The Directory Level

df tells you how full a filesystem is overall. It has nothing to say about which files or directories are actually responsible for that usage. du (“disk usage”) answers that instead, by walking a directory tree and summing up file sizes.

du -h /var/log

Run without any further flags, du prints a size for every single directory in that tree, recursively — often far more output than you actually want. Two flags fix that in practice:

du -sh /var/log

-s (“summarize”) collapses the whole tree into a single total, instead of a line per subdirectory — usually the actual question you’re asking.

Hunting For What’s Actually Taking Up Space

The genuinely useful pattern, and one of the most common real troubleshooting moves in this entire section: check each item in a directory individually, sorted largest first.

du -h --max-depth=1 /var | sort -rh

--max-depth=1 shows one level of subdirectories rather than the full recursive tree, and sort -rh — reverse, human-numeric — sorts the result largest first, using exactly the piping skills from the grep and sed files earlier in this course. This single line is very often the fastest way to answer “what’s actually filling up this disk” without wading through a fully recursive du listing by hand.

Why df And du Can Disagree

This is the gap worth understanding properly, because it produces a genuinely confusing situation the first time you hit it: df reports a filesystem as nearly full, but summing up everything with du across the entire filesystem comes up far short of that number — the space seems to have simply vanished.

The explanation traces directly back to the lsof/fuser chapter from Processes & Job Control, and the inode explanation from the Filesystems chapter in this section. When a file is deleted, its directory entry — the name — is removed immediately. But if some process still has that file open at the time, the actual data isn’t freed yet; the inode and its data blocks stick around, invisible to anything that walks the directory tree (which is exactly what du does), but still fully counted by df, which reports space at the raw filesystem level, independent of whether any name currently points at that data.

A classic real-world cause: a service writing to a log file that gets deleted (say, by a naive cleanup script) while the service is still running and still has that file open for writing. The file is gone from ls, gone from du’s calculation, and yet the disk keeps filling up, because the service keeps writing into space that’s still allocated to that now-nameless inode.

Finding Deleted-But-Still-Open Files

lsof, from the Processes & Job Control section, is exactly the right tool to confirm this diagnosis:

sudo lsof +L1

+L1 filters lsof’s output to files with a link count of less than 1 — meaning no directory entry currently points to them, precisely the definition of “deleted but still open” from the explanation above. Any result here is a genuine candidate for exactly the mismatch just described, and the PID column, exactly as covered back in the lsof chapter, tells you which process to investigate — restarting that process, once you understand why it’s holding a deleted file open, is very often the actual fix.

What’s chapter

You can now measure both overall filesystem usage and drill down to find exactly what’s responsible for it, including the genuinely tricky deleted-but-open case. The next chapter introduces a tool that operates at a lower level than anything covered so far — dd, for cloning and imaging disks directly, bypassing filesystems entirely.