Why df and du show different Linux disk usage
Understand why df and du differ on Linux, including metadata, reserved blocks, open deleted files, permissions, sparse files, and mount boundaries.
Direct answer
df reports allocation for a filesystem, while du walks reachable directory entries and estimates their disk usage. Because they observe different layers, exact agreement is not expected; a large gap can point to deleted-but-open files, inaccessible paths, covered mount content, snapshots, reserved blocks, or filesystem metadata.
When this guide applies
- df says a mount is full but the visible directory tree is much smaller.
- Free space did not return after a pathname was removed.
- You need to explain why a visual scan cannot account for every allocated block.
Step-by-step review
Align the scope
Compare df for the exact mount with du for that mount while controlling cross-filesystem traversal.
Confirm units and semantics
Check whether values are human-readable, bytes, blocks, logical size, or allocated usage.
Record visibility gaps
Permission failures and skipped mounts mean du-style traversal is incomplete.
Investigate filesystem-only allocation
Check for deleted-but-open files, snapshots, reserved blocks, metadata, and content hidden below a mount point using appropriate administrator tools.
Re-measure after the owner acts
Verify the same filesystem and scope rather than trusting an estimated reclaim value.
Technical context
The difference is architectural
GNU documents df as filesystem space reporting and du as hierarchy-based estimation. They are complementary tools rather than interchangeable calculators.
Deleted names can keep allocated data
Unlinking a pathname does not necessarily release its blocks immediately when a process still holds the file open.
Apparent size is another axis
du can report apparent size separately from allocated usage; sparse files make the distinction especially visible.
Exact reconciliation can be filesystem-specific
Snapshots, copy-on-write, compression, deduplication, and reserved space require tools and knowledge for the actual filesystem.
df and du answer different questions
| Measure | df | du-style scan |
|---|---|---|
| Primary scope | Mounted filesystem | Reachable paths below a directory |
| Needs a tree walk | No | Yes |
| Deleted-but-open data | Still allocated | No pathname to visit |
| Unreadable directories | Included in filesystem total | Cannot be fully counted |
| Best use | Capacity and free-space alert | Locate visible directory consumers |
Risks and actions to avoid
Do not force totals to match
Changing options until two numbers look equal can hide a scope or semantic mismatch.
Do not close processes casually
An open deleted file can belong to a critical service; coordinate a documented restart or log-reopen procedure.
Do not call the gap reclaimable
Some difference belongs to metadata, snapshots, reservations, or inaccessible data rather than disposable files.
What the Omuuz product can—and cannot—do
What it can do
SSH Disk Visualizer can keep filesystem capacity beside metadata-derived directory totals and show scan gaps so the two measurements are not conflated.
What it cannot do
It cannot enumerate an unlinked file by pathname, reconcile every filesystem feature, or claim that the difference can be reclaimed.
Product evidence
