mediumScenarioConceptMidSenior
df says the filesystem is 100% full but du only accounts for half of it. What is going on?
df and du disagree because df reads filesystem block allocation while du walks visible directory entries. Deleted-but-open files, inode exhaustion, hidden files under mounts and reserved blocks are the usual causes. Use this LINUX answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects filesystems to the point an interviewer is testing.
4 min readUpdated 2026-08-15
Answer
Short answer
df can show full while du shows less because df counts allocated filesystem blocks and du only sums files it can see. Check for deleted files still held open by processes, exhausted inodes, files hidden under mount points, and reserved blocks that normal users cannot use.
Was this answer helpful?
Likely follow-ups
- You truncate the file descriptor and the process keeps writing. What happens to the file it is writing into?
- df -i shows 100% used with gigabytes of blocks free. Where would you look, and what created that situation?
- Why does deleting files from a directory sometimes not shrink the directory itself?
- The filesystem is XFS rather than ext4. Which parts of your answer change?
Related questions
- A service stops accepting new connections while CPU and memory look fine. Which operating-system limits would you suspect, and how would you tell them apart?hardAlso on file-descriptors and linux5 min
- Your application cannot reach a service that should be up. Walk me through diagnosing it from the shell.mediumAlso on troubleshooting6 min
- A service dies with OutOfMemoryError in production. Walk me through diagnosing it.hardAlso on troubleshooting6 min
- Your GC log shows a stop-the-world pause far longer than the collection work inside it. Where did the rest of the time go?hardAlso on troubleshooting5 min