Which folder is eating the disk? du, sorted by biggest

du -h --max-depth=1 . | sort -rh gives you one level of the tree, largest first. You then repeat it inside the biggest entry until you find the culprit. That descent — not one clever command — is the technique.

1. One level, biggest first

$ clai show folder sizes here, one level deep, biggest first→ du -h --max-depth=1 . | sort -rh348K	.296K	./a52K	./c

sort -rh sorts human-readable sizes correctly — it knows 2G outranks 900M, which a plain sort -r does not.

2. Go where the size is

$ clai now do the same inside the biggest folder→ du -h --max-depth=1 ./a | sort -rh

Two or three iterations of this usually lands on the answer. It beats a full-tree scan because you never read the branches that don't matter.

3. Don't count other filesystems

$ clai total size of / but stay on this filesystem only→ du -shx /348G	/

-x keeps du from descending into other mounts. Without it, a scan of / wanders into /mnt, network shares and bind mounts, and reports a number that has nothing to do with the disk you're trying to free.

4. The biggest individual files

$ clai find the 10 largest files under /var→ sudo find /var -xdev -type f -printf '%s\t%p\n' | sort -rn | head -10

Sometimes it isn't a folder, it's one 40 GB log. -xdev is find's equivalent of du -x.

5. Browse it interactively

$ clai browse disk usage interactively under /var→ ncdu -x /var

ncdu scans once and lets you walk the tree with arrow keys, deleting as you go. If you're going to run du more than twice, install it instead.

6. Run it where it's allowed to read everything

$ clai scan / for folder sizes without permission noise→ sudo du -h --max-depth=1 -x / 2>/dev/null | sort -rh | head

Without sudo, du silently skips directories it can't enter and undercounts. With it, 2>/dev/null hides the churn from files that vanish mid-scan.

Gotchas

• du measures allocated blocks, not file contents. A million 1-byte files occupy far more than a million bytes. du --apparent-size shows the other number.
• If du and df disagree by a lot, stop. That's a different problem — deleted files still held open, or exhausted inodes. See the linked article.
• --max-depth is GNU-only. On macOS the equivalent is du -d 1, and sort -rh needs a recent BSD sort or coreutils.

Related questions

Why is du so slow? It stats every file in the tree. On network filesystems or millions of small files this is genuinely slow — narrow the path or use ncdu, which at least caches the scan.

What's the difference between du -s and du -h --max-depth=1? -s prints one total for the whole path; --max-depth=1 prints a line per child. Use -s when you already know where to look.

How do I find folders over a certain size? Pipe through awk: du -m --max-depth=2 . | awk '$1 > 1000' lists everything above 1 GB.

See also

• Stop memorizing find flags: ask for what you want
• df says the disk is full, du says it isn't
• Docker ate your disk: how to get the space back

Ask for the folder sizes you want and CliAI writes the du, the sort -rh and the -x. Install it in one line.