Linux disk full with no obvious large file: find deleted files and inode exhaustion
When df and du disagree, a deleted file may still be held open by a process. The other common cause is inode exhaustion from many small files.
Maintained by Kevin · Ovalk
Scope and prerequisites
Linux filesystems with df, du, findmnt and lsof. Snapshots, reserved blocks and permissions can also explain differences between tools.
Identify the filesystem that rejects writes, not just /. Some diagnostics need elevated read access. Capture file ownership and retention requirements before proposing cleanup.
Common symptoms
- df reports 100% while du is much smaller.
- Services fail with no space left on device.
- A filesystem cannot create files despite few visible large files.
1. Separate blocks from inodes
Run df for capacity and inodes before acting. Inode exhaustion calls for removal of many small files; block exhaustion needs path and held-file analysis.
df -h
df -i
du -xhd1 / | sort -h2. Locate open deleted files
Files deleted from the directory tree still consume space while held by a process. Use lsof to identify owners and prefer application log rotation or a targeted restart over truncating unknown files.
lsof +L1
lsof +L1 | sort -k7 -n3. Fix the source after restoring headroom
Expansion buys time but does not solve log policy, temporary-file lifetime, or an application writing to the wrong mount. Verify the real mount point used by the workload.
findmnt -T /path/to/application/data
journalctl --disk-usageInterpret the evidence
| Observation | What to check next |
|---|---|
| Blocks free, inodes exhausted | Look for an unexpectedly large count of small files on this mount. Deleting one large file will not recover many inodes. |
| df exceeds readable du totals | Check open deleted files, snapshots, reserved space and inaccessible paths; the difference alone does not prove a leak. |
| Expected data mount is absent | Stop or redirect writes through the approved process before remounting. Files written beneath a mount point need a separate recovery plan. |
Illustrative diagnosis
A hypothetical example to explain the reasoning, not a reported customer incident or a claim of testing on your stack.
A 40 GB log is deleted but df does not improve. lsof shows the logging process still holds its descriptor. Deleting other directories would not address that allocation. Ask the service owner to reopen logs using the supported mechanism, then confirm the descriptor is gone. A restart is only a fallback after checking availability.
Verify recovery
- Check both available blocks and inodes on the exact workload path. Have the application perform a normal small write and read through its own account.
- Watch the consumption rate after recovery and confirm log rotation actually creates and retires files as intended.
Rollback and stopping point
Cleanup is not generally reversible. Do not delete business data or unknown files without a verified backup and retention decision. Keep any service configuration changes separately reversible.
Prevention and long-term repair
- Separate capacity and cleanup policy for logs, temp files, uploads, and data.
- Alert independently at 70%, 85%, and 95% for blocks and inodes.
- Test log rotation and safe reload before an incident.
References and corrections
Use the documentation for your installed version. The references below explain the underlying behavior; commands still need environment-specific validation.
Report a correction to Kevin — include the page URL, version and a redacted reproduction. See our editorial policy.