fun with df..
bde at zeta.org.au
Tue Jan 13 15:58:58 PST 2004
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
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.
More information about the freebsd-current