A server reports the disk is full. Walk me through finding what is using the space.

Question

Accepted Answer

First df -h to see which mount is actually full, because it is often not /, it is /var sitting at 100 percent from logs. Then du to localize it, du -ahx /var, sorted with sort -rh and piped to head -20, ranks the 20 heaviest directories and files and usually one of them is obviously the problem. If df says the disk is 100 percent full but du only accounts for, say, 20 gigabytes of it, that gap is the classic trap. A process is holding a deleted file open, so the space is not returned until that handle closes. lsof piped through grep deleted finds it, and restarting that process, often a logger, frees the space instantly. I would also run df -i for inode exhaustion, because millions of tiny cache or session files can hit 100 percent of inodes while df -h still shows free space, and the error message looks identical. Then I fix the cause rather than just buying time: logrotate with a size cap and 7 days of retention, clean the package and build caches, and an alert at 80 percent so it warns me before it silently refills.

Answer

du and df disagree on usage. What is happening?

Almost always a deleted-but-still-open file: the directory entry is gone (du does not see it) but the space is held until the process closes the descriptor. lsof +L1 or lsof | grep deleted; restart the holder.

Answer

Disk space is free but you still get "No space left on device". Why?

Inode exhaustion, df -i. Too many small files used up all inodes. Delete unneeded small files or recreate the filesystem with more inodes.

A server reports the disk is full. Walk me through finding what is using the space.

A server reports the disk is full. Walk me through finding what is using the space.

The follow-ups they ask next

What the interviewer is listening for

What sinks the answer

If you genuinely do not know

Keep going with linux

Knowing the answer is not the same as recalling it under pressure