Re: fun with df..

On Tue, 13 Jan 2004, Nate Lawson wrote:

> On Mon, 12 Jan 2004, Wilko Bulte wrote:
> > My laptop just presented me with a funny one:
> >
> > wkb_at_chuck ~: df
> > Filesystem  1M-blocks Used             Avail Capacity  Mounted on
> > /dev/ad0s2g      4032 3842 36028797018963835   104%    /usr
> > /dev/ad0s2e        62    6                51    12%    /var
> >
> > ....
> >
> > wkb_at_chuck ~: df -k
> > Filesystem  1K-blocks    Used   Avail Capacity  Mounted on
> > /dev/ad0s2g   4129310 3934638 -135672   104%    /usr
> >
> > Oldish 5.x- (Dec 17)
>
> Note the M/K flags.  Someone is probably using an unsigned for the M
> printing and a (correct) signed for the K printing.

I note that there is no -m flag.  The 1M blocks apparently come from
statfs(), but that shouldn't happen.

If this is for an nfs file system, then there are many bugs in this
area that could produce output like the above.  See PR 56606 and wrong
fixes for earlier bug reports in nfs_vfsops.c revs 1.133 and 1.135.
The 64-bit statfs changes should have made the bug in nfs moot, but
it is missing removal of bogus casts and revs 1.133 and 1.135.  A
non-broken version of revs 1.133 and 1.135 is needed in cvtstatfs()
(not in nfs) to fudge the block size so that large block counts
can be represented (cvtstatfs() currrently uses truncation where nfs
used overflow, except for large negative block counts cvstatfs() also
uses overflow).

The 64-bit statfs changes also implemented lots of sign extension bugs.
One of them is probably responsible for the large positive block count.
The magic number 36028797018963835 is approximately 2^64/512.

Bruce