Disk usage — finding what's actually eating your space

Confusing these wastes time — running du on an entire root filesystem looking for "is the disk full" when df already answers that in one line is a common way to make a two-second question take five minutes.

-h means "human-readable" (GB/MB instead of raw byte counts) — worth using by default, since raw byte counts are hard to read at a glance. A Use% near 100% is the actual "disk full" signal — and it's checked here, at the filesystem level, before going any further.

Once you know the disk is full, du narrows down where:

(du -sh * looks like the obvious shortcut, but the * glob skips hidden entries like .git — which is often exactly where the space went. Naming the directory and using -d 1 includes them, and the first line, ., is the directory's own total.)

sort -rh sorts human-readable sizes correctly, largest first — sorting without -h would incorrectly treat "1.8G" as smaller than "890M" since it'd compare the strings, not the actual sizes. This pattern — summarize, then sort by size, then look at the top few — is the standard way to quickly find what's actually consuming space in a directory tree, one level at a time, drilling into whichever entry turns out to be the largest.

find searches for files matching specific criteria, rather than summarizing size:

"The disk is full" breaking a deployment or crashing a database is a real, recurring production incident category — and diagnosing it quickly depends entirely on knowing which of these three tools actually answers the question in front of you, rather than guessing. df first (is it actually full, and where), then du (which directory), then find (which specific files) is the standard, fast path from "something's wrong" to "here's exactly what to delete or move."