Free tools Windows power users keep installed
One-click scans. No signup required.
To find out why a Linux filesystem is full, check block space and inode availability separately: run df -h for space and df -i for inodes. Then use du to locate the directories consuming the affected resource. Delete files only after confirming what they are and whether the service or application still needs them.
First determine whether blocks or inodes are exhausted
Block space is the filesystem capacity used to store file data. Inodes are filesystem records associated with files and directories; a filesystem can run out of available inodes even while it has room for more bytes. The two problems need different investigations, so check both.
As an Amazon Associate I earn from qualifying purchases.
df -h
df -iGNU df reports the filesystem containing each path you name. Its -h option displays block figures in human-readable units, while -i reports inode information instead of block usage. See the GNU df(1) manual. To focus on the filesystem containing a particular location, pass that path, for example df -h /var and df -i /var.
Read the relevant mount row and compare its available blocks or inodes with its total. If Use% is high in df -h, investigate allocated space; if inode use is high in df -i, look for large numbers of files and directories. Do not assume one percentage tells you about the other.
#1 Best Overall
Find which directories account for the usage
df describes a whole filesystem. GNU du recursively estimates usage within a directory tree, which helps narrow the search. For a one-level summary under a path, try:
sudo du -xhd1 /varReplace /var with a directory on the affected filesystem. The options mean human-readable output (-h), one level of depth (-d1), and stay on the same filesystem (-x). GNU du summarizes device usage recursively; consult the GNU du(1) manual and check your installed version if an option is unavailable.
For inode counts in immediate subdirectories, GNU du also offers:
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →sudo du --inodes -x -d1 /varUse the results to choose a likely contributor, then run the same kind of scan on that subdirectory to drill down. A directory with many small files can account for heavy inode use without being the largest in bytes.
du estimates allocated filesystem usage, not necessarily the apparent length of file contents. Sparse files and allocation behavior can make those figures differ. Symbolic links also matter: POSIX specifies that du counts the link itself and does not follow it by default; behavior or options may vary by implementation. See the POSIX du specification.
Inspect candidates before removing anything
Once a subtree stands out, list and identify its contents before acting. File age, size, or a familiar-looking name does not prove that a file is disposable. Confirm its owner, purpose, and whether a running service or application relies on it. If you are unsure, consult the documentation for that service or your distribution rather than deleting files directly.
To search for candidates, constrain find to the relevant subtree and first print matches for review. For example, this previews regular files older than 30 days under a chosen path; it does not establish that they are safe to remove:
find /var/some-directory -type f -mtime +30 -printBe especially careful when passing filenames to another command. Newlines and spaces can make ordinary newline-separated output ambiguous. GNU find documents the safer NUL-delimited pattern:
find /var/some-directory -type f -mtime +30 -print0 | xargs -0 -r ls -ld --This lists matching paths with their details; it still does not determine whether any file is safe to delete. The GNU find(1) manual explains why NUL delimiters avoid filename parsing problems. Avoid turning an exploratory search directly into a deletion pipeline.
Rank #4
Use a cleanup method that matches the confirmed cause
Systemd journal files
If journal data is a confirmed contributor on a system using systemd, inspect its usage first:
journalctl --disk-usageYou can remove eligible archived journal files by size, for example:
sudo journalctl --vacuum-size=1GThe 1G value is an example, not a universal retention recommendation. Choose a limit that preserves the logs needed for troubleshooting, auditing, or local policy. Journal vacuum commands act on archived files, not active journal files, so the chosen size is not necessarily the total journal footprint. The journalctl manual documents vacuuming behavior.
Best Value
For ongoing journal limits, review the settings documented in journald.conf, including maximum-use and free-space controls. A configured limit does not mean existing data is always immediately trimmed to that size.
Package caches, containers, and application data
There is no single safe cleanup command for every Linux distribution or workload. Package managers, container runtimes, databases, and applications each have their own rules for caches, images, logs, and persistent data. Use the documentation for the installed distribution or software, verify what a cleanup operation removes, and check whether it can affect rollback, rebuild, or retention needs. Do not remove files from a service’s data directory merely because they are large.
Verify the result and continue only if needed
After a cleanup, rerun both filesystem checks for the affected path:
df -h /var
df -i /varCompare the relevant block and inode figures with your initial readings. If the intended resource did not improve, do not assume that deleting more files is the answer: revisit which filesystem the path belongs to and whether the directory scan identified the actual contributor.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
