On Tue, 16 Feb 1999 21:26:24 -0500, Chris Brown wrote:
> 
> The only thing I haven't been able to figure out is why df is lying to me.

There has been this bug for quite a while, but I cannot offer you an
explanation.  Someone else might...

> This is the output I get when I type df:
> 
> Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
> /dev/sd0a       49391    11670    32781    26%    /
> /dev/sd0g      247262   192880    29655    87%    /usr
> /dev/sd0d       97677     1484    86425     2%    /var
> /dev/sd0f      282000   102551   151249    40%    /home
> /dev/sd0h      346189   282009    29561    91%    /tmp
> kernfs              1        1        0   100%    /kern
> procfs              4        4        0   100%    /proc
> 
> Next is the output from disklabel, and the actual partition sizes as I
> created them. The sectors are 512k, so divide by 2 to compare with the
> numbers above. The one that worries me the most is /tmp , which should
> be 66510 kbytes, but instead is showing up as 346189, with only 29561
> free. Yet du says /tmp is only using 9 blocks...

The size of /tmp is definitely incorrect, but 29561 1K-blocks free may
not be incorrect.  With du, you can calculate only the number of
blocks used by the named files; i.e. files that have a directory entry
pointing at them.  If you unlink open files, they will remain in the
filesystem occupying inodes and blocks as long as the processes which
opened the files are alive but they are now unnamed thus omitted from
du's calculation.  So, there is a plausible explantion, although I
can't say that's what is really happening in your case.

Ken