df & du showing different usages for /var
alex at schnarff.com
alex at schnarff.com
Wed Feb 6 20:13:27 UTC 2008
>> After nearly running out of space on my /var partition recently, I went
>> in to clean things up and ensure that it didn't happen again. Using the
>> "du" command to look for offending directories and files, I wiped out a
>> bunch of old Apache and Qmail logs...and then found that I was still
>> using 90% of the partition. So I cd'd over to /var, and got this rather
>> surprising set of results:
>> [alex at tms /var]$ sudo du -sh
>> 395M .
>> [alex at tms /var]$ df -h
>> Filesystem Size Used Avail Capacity Mounted on
>> /dev/ad4s1a 484M 126M 320M 28% /
>> devfs 1.0K 1.0K 0B 100% /dev
>> /dev/ad4s1f 269G 40G 207G 16% /data
>> /dev/ad4s1d 9.7G 7.2G 1.7G 81% /usr
>> /dev/ad4s1e 1.9G 1.6G 173M 90% /var
>> These wildly different results have me confused. How in the world can
>> there be a ~1.2GB difference between the disk space in use as reported
>> by these two tools?
> Because they calculate the space differently.
>> Which is right?
> They're both right ... in the manner that they calculate it.
>> More importantly, how do I fix this?
> Well, this depends on your definition of "fix".
> If you mean fix du and dh, there's nothing to fix, they're doing their
> job exactly correctly. du calculates the used space by looking at each
> file in each directory. df calculates it by looking at low-level ffs
> If you have one program with a file open, and delete that file with
> another program, you create a discrepancy between how df and du operate.
> Since there is no longer a directory entry, du doesn't count the space,
> but since the other program still has the file open, the filesystem still
> has the space allocated and used, so df sees the space. This is the
> correct behaviour.
> If you mean, how do I actually free up space, the answer could come in
> a number of ways. Generally, the easiest thing to do is just reboot the
> system. Whatever program has space reserved will exit and the filesystem
> will reclaim it. (If the space doesn't free up after a reboot, something
> else is wrong)
> If a reboot isn't an option, you can often figure out what's going on
> by comparing the list of open files provided by fstat with a list of
> files that you were deleting. You might then be able to free up the
> space simply by restarting a single program: possibly Apache or qmail.
Thanks for such a thorough and prompt response. Given Erik's reply, it
looks like I've inadverdently asked an FAQ...and reading the entry he
pointed me to, it makes perfect sense what's going on, and a simple
restart of Apache fixed things up.
More information about the freebsd-questions