Troubleshooting Disk Space Issues with du and df

A full Linux filesystem can stop package updates, crash services, and prevent users from logging in. The fastest diagnosis usually begins with two commands: df, which reports filesystem capacity, and du, which measures space used by files and directories.

These tools answer different questions, so their output may appear inconsistent. This guide explains how to find large directories, identify deleted files still held open, check inode exhaustion, and clean up safely on RHEL, CentOS, Fedora, and similar systems. The examples suit environments ranging from a small Melbourne office server to workloads hosted in Sydney data centres.

Reading Filesystem Reports

Start by checking mounted filesystems in a readable format:

df -hT

The -h option converts blocks into familiar units, while -T displays the filesystem type. Pay attention to the Use% column and the mount point. A root filesystem at 95% may be more urgent than a large data volume at 99%, because /, /var, and /tmp support core operating system functions.

Check inode consumption separately:

df -ih

A filesystem can have free gigabytes but no free inodes when it contains millions of small files. Mail queues, cache files, session data, and application-generated logs commonly cause this condition.

Locating Large Directories

To inspect the root filesystem without crossing into other mounts, use:

sudo du -xhd1 / 2>/dev/null | sort -h

The command summarises directories one level below /. The -x option keeps the scan on the same filesystem, preventing a mounted backup disk or NFS share from distorting the result. Repeat the command inside a large path such as /var:

sudo du -xhd1 /var 2>/dev/null | sort -h

For a ranked view of individual files, run:

sudo find /var -xdev -type f -printf '%s %p\n' 2>/dev/null |
  sort -nr | head -20

This helps expose oversized database dumps, core files, ISO images, and application logs. On a server scheduled in AEST or AEDT, correlate file timestamps with the nightly backup and log rotation jobs before removing anything.

Understanding Differences Between du and df

df reads filesystem accounting maintained by the kernel. du walks visible directory entries and adds the blocks assigned to those files. Their totals can differ for several legitimate reasons, including reserved blocks, sparse files, snapshots, and files that have been deleted while a process still has them open.

Use these comparisons when investigating an apparent mismatch:

Check	Command	What it reveals
Filesystem capacity	df -hT	Used and available blocks by mount
Directory usage	du -xhd1 /path	Space visible below a directory
Inode usage	df -ih	Exhaustion of file and directory entries
Open deleted files	sudo lsof +L1	Space held by running processes
Apparent file size	du -h --apparent-size file	Logical size, including sparse regions

A deleted log file remains allocated until every process closes its file descriptor. If df shows a full filesystem but du cannot find enough data, inspect open deleted files:

sudo lsof +L1

Restart the responsible service through its normal systemd procedure, or ask it to reopen logs when supported. Avoid deleting files from /proc or forcibly terminating production processes without understanding the impact.

Checking Mounts And Inodes

A directory such as /var/lib may be a separate mount, so a scan from / can conceal where the actual capacity is being consumed. Review the mount layout with:

findmnt
lsblk -f

Then run du against each relevant mount. The -x option remains important when a server uses separate filesystems for /home, /var, backups, or container storage.

If df -ih reports 100% inode usage, search for directories containing huge numbers of small files:

sudo find /var -xdev -type f -printf '%h\n' 2>/dev/null |
  sort | uniq -c | sort -nr | head

Clean the application’s supported cache or queue rather than manually removing arbitrary files. In regulated Australian businesses, records affected by the Privacy Act 1988 or industry retention rules may need authorised handling before deletion.

Applying Safe Cleanup Practices

First establish what created the data and whether another process depends on it. Package caches, old journal entries, temporary files, and rotated logs are often safe targets, but database files, mail queues, and backup archives require application-specific procedures. Keep an audit trail where operational controls require it.

Useful cleanup checks include:

• sudo journalctl --disk-usage
• sudo du -sh /var/cache/*
• sudo find /tmp -xdev -type f -mtime +7 -ls
• sudo logrotate -d /etc/logrotate.conf

Avoid broad commands such as rm -rf /var/*. Prefer the package manager, systemd journal controls, or an application’s documented maintenance command.

Before removing files, verify:

• The path is on the affected filesystem.
• The file is not an active database, queue, or socket.
• A current backup or recovery method exists.
• The owner and retention policy permit deletion.

Considering Permissions And Services

A normal user may see less usage than df because they cannot read every directory. Run diagnostic commands with sudo, while still treating output as sensitive. File ownership, modes, ACLs, and umask can affect whether a service can rotate or remove its own logs; this permissions and umask guide provides useful background.

Check service status and recent errors after cleanup:

systemctl --failed
journalctl -p warning..alert -b

If a web service is involved, inspect Nginx access and error logs, then confirm that rotation is configured. Administrators supporting Australian organisations may also need to document access to customer data and coordinate changes during an approved maintenance window.

Preventing Recurring Capacity Problems

Disk monitoring should track both percentage usage and absolute free space. A 20 GB filesystem can reach a critical threshold quickly even when its percentage appears manageable. Set alerts before 90%, and use lower thresholds for systems that require free working space for upgrades or database operations.

Automate regular checks with systemd timers, monitoring software, or a small shell script. Review log retention, journal limits, container image cleanup, and backup expiry. When managing mixed Linux and Windows estates, keep platform-specific procedures separate; a registry troubleshooting reference may help with the Windows side, but it does not replace Linux filesystem checks.

A practical incident sequence is simple: run df -hT and df -ih, identify the affected mount, use du -x to narrow the directory, check lsof +L1 for hidden allocations, and clean only data whose ownership and retention are clear. For site-specific questions about publishing or maintaining Linux guidance, use contact the team.