How to Check Disk Space in Linux: df, du, and Practical Cleanup

Running out of disk space on a Linux server is one of those failures that announces itself at the worst possible moment — a database crashes, logs stop writing, or deployments fail because the filesystem is full. Knowing how to check disk space in Linux and interpret the results correctly is a basic but critical skill for anyone managing Linux systems. This guide covers the df and du commands in depth, explains what the output actually means, and walks through targeted cleanup strategies.

The df Command: Checking Free Disk Space Across Filesystems

The df command (disk free) reports available and used space for every mounted filesystem. Running it without arguments produces output that includes filesystem names, block counts, and mount points:

df

The output is almost always more useful in human-readable format:

df -h

Sample output:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   38G  9.2G  81%  /
tmpfs           2.0G  1.1M  2.0G   1%  /dev/shm
/dev/sda2       100G   45G   55G  45%  /home

The Use% column is what most administrators watch. A root filesystem above 85% warrants investigation. Above 95%, many systems start behaving erratically as temporary files fail to write and logging breaks.

Reading df Output Correctly

The Filesystem column shows the block device or filesystem type. tmpfs entries are RAM-backed temporary filesystems — they consume memory, not disk space. The /dev/shm mount is a shared memory filesystem; its usage reflects processes that use shared memory, not disk writes.

The Available column shows actual usable space, which is slightly less than (Size – Used) because ext4 reserves approximately 5% of capacity for root processes by default. This reserved space prevents regular users from completely filling a filesystem in a way that locks out root administration.

To show disk space for a specific directory’s filesystem only:

df -h /var

To include filesystem types in the output:

df -hT

The -T flag adds a Type column showing ext4, xfs, tmpfs, and other filesystem types — useful when managing systems with multiple filesystem formats.

The du Command: Finding What Is Using Your Disk Space

df tells you that space is used — du (disk usage) tells you where. After confirming a filesystem is nearly full with df, the du command identifies the directories and files consuming the most space.

Summarize the total disk usage of a directory:

du -sh /var

Show the size of each immediate subdirectory inside /var:

du -h --max-depth=1 /var | sort -h

The sort -h flag sorts by human-readable size values (K, M, G) rather than alphabetically. This immediately shows which subdirectories are the largest contributors.

Finding the Largest Files on the System

To identify individual large files anywhere on the system:

find / -type f -size +100M -exec du -h {} + 2>/dev/null | sort -rh | head -20

This finds files larger than 100 MB, lists their sizes, and shows the top 20. The 2>/dev/null suppresses permission denied errors from directories you cannot read.

For a faster approach on systems with the ncdu tool installed:

sudo apt install ncdu
sudo ncdu /

ncdu is an interactive disk usage analyzer with a navigable interface. It recursively scans a directory tree and presents usage by size, making it significantly easier to navigate large directory structures than reading du output in a terminal.

Common Sources of Unexpected Disk Usage

Log Files

Logs are the most common cause of unexpected disk consumption on Linux servers. Application logs, system logs, and journal files can grow to hundreds of gigabytes on active systems without rotation configured.

Check the journal size:

journalctl --disk-usage

Reduce it to 500 MB:

sudo journalctl --vacuum-size=500M

Check /var/log for large files:

du -h --max-depth=1 /var/log | sort -h

Individual log files can be compressed with gzip or truncated safely if the service is not actively writing:

sudo truncate -s 0 /var/log/application.log

Package Manager Caches

APT on Debian/Ubuntu caches downloaded packages in /var/cache/apt/archives. This cache grows with every package installation and update:

du -sh /var/cache/apt
sudo apt clean

apt clean removes all cached packages. apt autoclean removes only packages that are no longer available in the repository. Both are safe to run on any production system.

Old Kernel Images

Each kernel update installs a new kernel image without automatically removing old ones. On systems that have been running for a year or more, this can accumulate several gigabytes:

dpkg --list | grep linux-image
sudo apt autoremove --purge

The autoremove command removes packages that were installed as dependencies but are no longer needed, including old kernel images. It preserves the currently running kernel and one previous version.

Managing disk space is directly connected to system stability on lightweight setups. The best lightweight Linux distros guide covers distributions that are designed with minimal footprint in mind — an approach that naturally reduces baseline disk consumption.

Setting Up Disk Usage Monitoring

Reactive disk management — checking usage only after something fails — is not adequate for production systems. Proactive monitoring catches issues before they cause downtime.

A simple cron-based alert checks disk usage and sends an email when a threshold is crossed:

0 * * * * df -h / | awk 'NR==2{print $5}' | tr -d '%' | awk '$1>85{print "Root disk above 85%"}' | mail -s "Disk Alert" [email protected]

For more sophisticated monitoring, Prometheus with the node_exporter exposes disk metrics that can trigger alerts through Alertmanager. This approach scales to monitoring dozens of servers from a single dashboard.

Log rotation prevents log-related disk exhaustion automatically. The logrotate tool runs daily and compresses, rotates, and removes old log files according to rules defined in /etc/logrotate.d/:

/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
}

This configuration keeps 14 days of compressed logs and discards anything older automatically.

Cleaning Up Docker Images and Containers

On systems running Docker, unused images and stopped containers can consume tens of gigabytes. Docker’s built-in prune commands handle cleanup:

docker system prune          # Remove stopped containers, unused networks, dangling images
docker system prune -a       # Also remove unused images (not just dangling ones)
docker volume prune          # Remove unused volumes

The -a flag on system prune is more aggressive — it removes any image not referenced by a running or stopped container. Use it with care if you have images you want to keep but are not currently running.

Combining automation with disk management pairs naturally with the tools described in the how to rename files in Linux guide — scripting repetitive file operations to keep directories organized prevents gradual accumulation of large files that go unnoticed until the disk is full.

Understanding Inodes: When the Disk “Fills Up” But df Shows Space

A filesystem can become unusable even when df shows available bytes, because Linux filesystems have a separate limit on the number of files (inodes) they can contain. Each file, directory, and symlink consumes one inode regardless of its size.

Check inode usage:

df -i

Directories containing millions of small files — mail queues, session storage, PHP session files — can exhaust inodes while the filesystem still has gigabytes of free space. The solution is either deleting large numbers of small files or reformatting the partition with a higher inode count.

A server where disk monitoring is combined with GRUB configuration awareness reduces recovery time when problems occur — the repair GRUB bootloader on Ubuntu guide covers the recovery steps needed when system partitions encounter serious problems.

Understanding df and du output, knowing where space typically accumulates, and building automatic monitoring transforms disk management from a reactive crisis into a predictable, controlled part of server operations.