You can recreate above scenario in your Linux system as follows:

 

 

First, note down /home file system output:

# df -h /home

# du -s -h /home

Now create a big file:

# cd /home/user

# cat /bin/* >> demo.txt

# cat /sbin/* >> demo.txt

Login on other console and open file demo.txt using vi text editor:

# vi /home/user/demo.txt

Do not exit from vi (keep it running).

Go back to another console and remove file demo.txt

# rm demo.txt

Now run both du and df to see the difference.

# df -h /home

# du -s -h /home

Login to another terminal and close vi.

Now close the vi and the root cause of the problem should be resolved, the du and df outputs should be correct.

 

 

If the apllication holding the file discriptor can not be found a reboot will also correct the problem.

Applies To

https://www.walkernews.net/2007/07/13/df-and-du-command-show-different-used-disk-space/ - df will say that the disk space is free when only the process which accesses it got terminated - du will only say the files which are having inode entry, - so the df and du will not match normally, - use lsof command to find that when there is difference.

Open file descriptor is main causes of such wrong information. For example if file called /tmp/application.log is open by third party application or by a user and same file is deleted, both df and du reports different output. You can recreate this scenario in your environment as follows: You can use lsof command to verify this: # lsof | grep tmp Output: bash 594 root cwd VDIR 0,86 512 2 /tmp bash 634 root cwd VDIR 0,86 512 2 /tmp pwebd 635 root cwd VDIR 0,86 512 2 /tmp pwebd 635 root 3rW VREG 0,86 17993324 68 /tmp (/dev/ad0s1e) pwebd 635 root 5u VREG 0,86 0 69 /tmp (/dev/ad0s1e) lsof 693 root cwd VDIR 0,86 512 2 /tmp grep 694 root cwd VDIR 0,86 512 2 /tmp You can see 17993324K file is open on /tmp by pwebd (our in house software) but deleted accidentally by me.