On Tue, 16 Feb 1999, Chris Brown wrote:

[output from df -k]
> 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
[output from disklabel, trimmed]
> #      size   offset      fstype   [fsize bsize   cpg]
> a:   102400   122976      4.2BSD        0     0     0   # (Cyl.  316*- 580*)
> d:   202300   634976      4.2BSD        0     0     0   # (Cyl. 1636*- 2157*)
> f:   381480   837276      4.2BSD        0     0     0   # (Cyl. 2157*- 3141*)
> g:   409600   225376      4.2BSD        0     0     0   # (Cyl.  580*- 1636*)
> h:   133020  1218756      4.2BSD        0     0     0   # (Cyl. 3141*- 3483*)
> 
> Can anybody tell me why df is saying such strange things about the size and
> capacity of the partitions? I'm running NetBSD-1.3.3-generic.

As has been mentioned, this is a known bug that is fixed in
-current. What it is actually doing (at least what mine was doing in
1.3.2) was adding the size of the previous partition to both the size
and amount used of the next partition. e.g.:

> Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
> /dev/sd0a       49391    11670    32781    26%    /

> /dev/sd0g      247262   192880    29655    87%    /usr
                 -49391   -49391 [49391 was size of sd0a]
                 ------   ------
         Actual: 197871   143489

> /dev/sd0d       97677     1484    86425     2%    /var

> /dev/sd0f      282000   102551   151249    40%    /home
                 -97677   -97677 [97677 was size of sd0d]
                 ------   ------
         Actual: 184323     4874

> /dev/sd0h      346189   282009    29561    91%    /tmp
                -282000  -282000 [282000 was size of sd0f]
                 ------   ------
	 Actual:  64189        9

For each of {sd0g,sd0f,sd0h} you would then recalculate the amount
available and pct capacity. Yours is a little odd in that the counter
"resets" between sd0g and sd0d, but the principle is the same as what
I was seeing. You should note that all the capacities that I
calculated are around 96.5% of the space listed in disklabel and that
/tmp once again becomes nearly empty. 

If for some reason you'd like to stay away from -current, you can
write a wrapper for df that will handle the calculations. I used a
perl script that you can have and modify if you'd like.

Dave Schmitt <dschmi1@umbc.edu>