Incorrect df -k output??

[illoai at gmail.com]

On 08/05/07, Peter Jeremy <peterjeremy at optushome.com.au> wrote:
> On 2007-May-08 13:04:55 +0400, Hanatsu Tori <hanatsu.tori at gmail.com> wrote:
> >xxxxx# df -k
> >Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
> >/dev/ad4s1a  76866422 51507978 19209132    73%    /
> >devfs               1        1        0   100%    /dev
> >*/dev/ad6s1d  77879478 75006042 -3356922   105%   /usr/home/ftp/pub/ARCHIEVE*
> >
> >
> >xxxxx# du -sk /usr/home/ftp/pub/ARCHIEVE
> >*75006042        /usr/home/ftp/pub/ARCHIEVE*
>
> df reports 75006042KB used and du reports 75006042KB used.  Where is
> the problem?
>
> >xxxxx# df -h
> >Filesystem     Size    Used   Avail Capacity  Mounted on
> >/dev/ad0s1a    496M     36M    420M     8%    /
> >devfs          1.0K    1.0K      0B   100%    /dev
> >/dev/ad0s1d    1.9G    425M    1.4G    23%    /tmp
> >/dev/ad0s1f    136G     70G     55G    56%    /usr
> >*/dev/ad0s1e    3.9G    3.6G    -21M   101%    /var
> >*/dev/ad2s1d    144G     25G    108G    19%    /hd2
> >procfs         4.0K    4.0K      0B   100%    /proc
> >
> >xxxxx# du -sh /var
> >*202M    /var*
>
> This is a bit less obvious - there does appear 3.4GB missing.

UFS witholds a certain amount of space.
See man 8 tunefs for details.

You can, of course, tunefs -m 0, which will
slow down writes quite enough.  There was
a thread some time back (last year?  two
years ago?) where a well intentioned fellow
rather verbosely (at least with regard to this
mailing list) went through the entire process
of trying to get those last few blocks available.
As i recall, in the end he concluded that the
naysayers were in fact correct.  Your "missing"
blocks are necessary for filesystem performance
and the overage above (which itself probably
well diagnosed in other messages) while obviously
not fatal to your system was likely dragging
performance down fairly significantly, at least
on that filesystem.

-- 
--