Why Does df Show More Used Space Than du? A Hands‑On Linux Demo

When checking disk usage on Linux, the df command often reports a larger used space than the du command. This article demonstrates the cause through a step‑by‑step experiment: creating a large file, keeping it open with tail -f, deleting the file, and observing that df still counts the space until the holding process terminates.

Experiment

Initial disk status:

# df -h
Filesystem      Size Used Avail Use% Mounted on
/dev/sda1        12G 5.7G 5.5G 51% /
tmpfs           506M   0 506M   0% /dev/shm

Create a 1 GB file:

# dd if=/dev/zero of=test.iso bs=1024k count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 14.3055 seconds, 73.3 MB/s

Disk after creation:

# df -h
Filesystem      Size Used Avail Use% Mounted on
/dev/sda1        12G 6.7G 4.6G 60% /
tmpfs           506M   0 506M   0% /dev/shm

Open the file with tail -f to keep it in use, then delete it:

# lsof | grep test.iso
tail 2175 root 3r REG 8,1 1048576000 752972 /tmp/test.iso

# rm /tmp/test.iso
rm: remove regular file ‘/tmp/test.iso’? y

Even after deletion, lsof shows the file as “deleted” but still held by the tail process, and df still reports the space as used.

Terminate the tail process (Ctrl+C) and check again:

# df -h
Filesystem      Size Used Avail Use% Mounted on
/dev/sda1        12G 5.7G 5.5G 51% /

The space is now released.

Explanation

The kernel only frees the disk blocks when the last process that has the file open closes it. df reads the filesystem’s allocation tables directly, while du walks the directory tree and therefore does not see the deleted but still‑open file.

Solutions

1. Identify and stop the processes holding deleted files: # lsof | grep deleted 2. Truncate the file instead of deleting it, which releases the space immediately:

# echo > /tmp/test.iso
# df -h

Truncating causes the kernel to discard the remaining blocks, and any process reading the file receives a “file truncated” message.

Additional Notes

Similar issues occur with tools like gzip that delete the original file after creating a compressed version while another process still holds the original.

Sparse files (files with large holes) can also appear large in metadata while occupying little actual space.