This is something I’ve run into a few times. I’ll pull up a `df -h` command and see something where the root directory (or /var or /usr) or something is filled up completely, and I try to locate where the space is with a `du -xh --max-depth=1 /directory_that_is_full` and the result shows me something completely different than the `df -hl`.
What I’ve found, this is something to do with a conflict of a process trying to access a file while something else was trying to delete the same file. Basically, the process goes into sort of a zombie mode, and the data is held and not removed. Because of the difference in the way du and df operate, they show different results.
The bad news, if the df says that the drive is full, the system will say that it can’t write to that drive/partition/mount, etc…. Even if the du says you have a ton of space.
To Locate the processes, run this command:
`lsof | grep deleted`
it should return the trouble processes and PID’s etc. If you kill those processes, it will allow the system to delete the files or whatever that are being held in limbo.
The problem: If you kill those processes, it could kill an application you are running. I recommend a clean `service restart` or a clean restart of the system itself(I know, I know, you should never have to do this in *nix systems because *nix is awesome and couldn’t possibly have to reboot to fix something like that horrible Microsoft junk!).
Just something that has come up a couple times for me in the last couple months and wanted to use it to help some folks out as it took me some hunting to get that info I needed.