When a Linux filesystem fills unexpectedly, first identify whether the space belongs to large files, large directory trees, logs, caches, containers, or files that were deleted but remain open by a process.
Find files larger than 800 MB
Search the current directory and sort results by allocated size:
1 | find . -type f -size +800M -print0 | |
-print0 and xargs -0 safely handle spaces, newlines, and non-ASCII characters in filenames.
To print the apparent file size directly:
1 | find /var -type f -size +800M -printf '%s %p\n' 2>/dev/null | |
Apparent size and allocated disk usage can differ for sparse files. Use du when investigating real filesystem consumption.
Find the largest directories
Start at one filesystem boundary and summarize the first level:
1 | sudo du -xhd1 / 2>/dev/null | sort -hr |
The -x option prevents traversal into mounted filesystems. Repeating the command inside the largest directory is often faster and easier to understand than scanning the entire server at once.
Show the largest files regardless of threshold
1 | sudo find / -xdev -type f -printf '%s\t%p\n' 2>/dev/null | |
This may still be expensive on systems with millions of files. Narrow the starting directory whenever possible.
Check deleted files that are still open
A process can keep disk blocks allocated after its log file has been deleted. Such files are invisible to normal directory scans:
1 | sudo lsof +L1 |
Restart or signal the owning service using its documented log-reopen procedure. Do not truncate arbitrary file descriptors in /proc unless you understand the application’s behavior.
Compare filesystem and directory usage
1 | df -hT |
If df reports a full filesystem but du totals are much smaller, common causes are deleted open files, reserved blocks, snapshots, mount points hiding underlying files, or filesystem metadata. If inodes are exhausted, df -ih will reveal it even when byte capacity remains.
Clean up safely
Before deleting anything, identify the owner and retention policy. Prefer application-aware cleanup such as journalctl --vacuum-time, package-manager cache commands, Docker pruning with reviewed filters, or log rotation. Removing an unfamiliar database, container layer, or active log can turn a capacity incident into data loss.
