du and df: Find What’s Filling Your Disk on Linux

When a Linux disk fills up, df says it is full but du cannot find the files. This guide shows how to use du and df together to find what is actually consuming space, interpret the disagreement between the two commands, and reclaim space safely.

Why df and du disagree

df reads filesystem metadata and reports allocated blocks. du walks the directory tree and sums file sizes. They measure different things, so they can disagree. The most common cause is a deleted file that a process still holds open: the directory entry is gone, so du cannot see it, but the inode and its blocks remain until the process closes them, so df still counts them.

If you delete a large log file and df still shows the disk as full, the file is likely held open by a running process. du will not show it because the directory entry is gone. df will still show it because the blocks are allocated.

Step 1: Confirm the disk is actually full

Start with df to see which filesystem is full and how much space is used.

“`bash
df -h
“`

Example output:

“`
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 50G 48G 1.2G 98% /
tmpfs 7.8G 0 7.8G 0% /dev/shm
“`

The `/` filesystem at 98% used is the problem. The `Avail` column shows only 1.2G free.

Step 2: Find the largest directories

Use du to walk the filesystem and sort by size, largest first. Start with top-level directories under root.

“`bash
sudo du -h –max-depth=1 / | sort -rh | head -20
“`

Example output:

“`
4.2G /var
3.1G /usr
1.8G /home
850M /root
420M /opt
“`

In this example, `/var` is the largest at 4.2G. Drill down into it:

“`bash
sudo du -h –max-depth=1 /var | sort -rh | head -20
“`

“`
3.9G /var/log
210M /var/lib
45M /var/cache
“`

`/var/log` is consuming 3.9G. Drill down further:

“`bash
sudo du -h –max-depth=1 /var/log | sort -rh | head -20
“`

“`
2.1G /var/log/syslog
850M /var/log/auth.log
420M /var/log/kern.log
“`

Now you have a specific file: `/var/log/syslog` at 2.1G.

Step 3: Find the largest individual files

If directory sizes do not reveal the culprit, search for individual large files.

“`bash
sudo find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null | sort -k5 -rh | head -20
“`

This finds files larger than 100MB, lists them with sizes, and sorts by size descending. The `2>/dev/null` suppresses permission denied errors.

Step 4: Check for deleted-but-open files

If df shows the disk full but du cannot find large files, a process may be holding a deleted file open. Use lsof to find deleted files still in use.

“`bash
sudo lsof +L1
“`

Example output:

“`
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rsyslogd 1242 root 4u REG 8,1 2199040 1234 /var/log/syslog (deleted)
“`

The `(deleted)` tag means the file was unlinked but rsyslogd still has it open. The `SIZE/OFF` column shows how much space the deleted file occupies.

Step 5: Reclaim space

For a normal large file, delete or archive it:

“`bash
sudo rm /var/log/syslog.1
“`

For a deleted-but-open file, deleting it again does nothing because the directory entry is already gone. You must restart or reload the process holding it open so it releases the inode:

“`bash
sudo systemctl restart rsyslog
“`

After restarting, run `df -h` again to confirm the space is reclaimed.

Important safety notes

• Never delete files in `/proc`, `/sys`, or `/dev`. These are virtual filesystems, not real files.
• Do not delete log files that applications are actively writing to unless you restart the application afterward.
• If you are unsure what a file does, move it instead of deleting it, then verify the application still works.
• On production systems, test in a staging environment first if possible.

Related commands

For disk-full emergencies where du and df disagree, see Linux Disk Full: A Troubleshooting Runbook for the full diagnosis order. For permission issues that prevent reading directories, see Linux File Permissions Reference: Modes, umask, and ACLs.