Linux Disk Space Explained: Check Usage with df and du

A server reports “No space left on device,” but which filesystem is full, and what is using it? Two Linux commands answer different parts of that question: df reports filesystem capacity, while du estimates usage beneath a directory.

This guide uses GNU tools on Linux. The inspection commands below do not remove files. Start with a specific affected path, then narrow the investigation. For broader checks, use our Linux server health checklist.

Find the filesystem that contains the affected path

df -h /var/log

The output describes the filesystem containing /var/log. Read Size, Used, Avail, Use%, and Mounted on. The -h flag formats sizes in powers of 1024. To include the filesystem type, use:

df -hT /var/log

Do not assume every directory shares the root filesystem. A separate mount for application data can be full while / still has room. Conversely, deleting something from a different mount will not help the full one.

GNU’s df documentation explains the fields and options. Available space can differ from total size minus used space because of filesystem reservations and accounting.

Check inodes when bytes are still available

df -i /var/log

On filesystems with a limited inode supply, many small files can exhaust that supply before data blocks fill up. Read IFree and IUse%. If inode usage is the problem, finding one huge file is the wrong next step: investigate directories accumulating large numbers of entries.

Neither free bytes nor free inodes rules out every storage problem. User quotas, a read-only mount, and application-specific limits can also prevent writes. Match your investigation to the actual error message.

Measure the directory you suspect

du -sh /var/log
sudo du -xhd1 /var | sort -h

The first command gives a summary. The second shows totals for /var and its immediate subdirectories, sorted by human-readable size. Here, -x keeps the walk on one filesystem, -h formats sizes, and -d1 limits the depth of the displayed directory totals. Deeper files still contribute to those totals.

The administrative command may be needed to read protected directories. Without sufficient access, du can report errors and incomplete totals. Scanning large directory trees also takes time and can create storage activity, so begin with a narrow path on a busy server.

If the largest relevant directory is /var/log, inspect one level further:

sudo du -xhd1 /var/log | sort -h

If application data resides on a separate mount, measure that mount directly. The -x flag intentionally excludes other filesystems beneath your starting directory.

Understand what du measures

By default, du reports allocated space rather than simply adding logical file lengths. Sparse files can have a large logical size while occupying fewer blocks. Compare the two views when needed:

du -h /path/to/file
du -h --apparent-size /path/to/file

Replace the placeholder with an actual file. Filesystem compression, shared extents, and snapshots can make physical storage accounting more complex. See the GNU du documentation for details.

Why df and du can disagree

They measure different things: df asks the filesystem for overall statistics; du walks reachable directory entries. Before treating a difference as mysterious, check that both commands refer to the same filesystem and that du completed without permission errors.

Another Linux behavior matters here: a deleted file can continue occupying space while a process keeps it open. Its pathname has disappeared, so an ordinary directory walk cannot count it. Closing the final reference allows the storage to be reclaimed. The Linux unlink manual describes this behavior.

Identify the owning application before considering a restart or log-reopening procedure. A restart can interrupt service, and deleting more unrelated files does not explain the original discrepancy.

Turn the finding into a specific fix

Suppose the application path is on a nearly full filesystem and du shows most of its usage under a backup directory. Your next question is which backups must be retained and whether verified copies exist elsewhere. If logs dominate, investigate the application producing them and its rotation policy. If small files dominate, inspect the lifecycle of the cache or temporary data.

After an approved cleanup or capacity change, rerun df against the original affected path. Confirm the application can write again and check whether usage is growing. A useful fix addresses both the immediate shortage and the process that created it.

Continue with our find command guide to locate files by name, size, or modification time.