What, exactly, are stat.st_blocks, statfs.f_b

[Rahul Dhesi]

Guy Harris writes:

     All you have to do to make a version of those utilities that
     reports in 1K units on S5R4 is to divide "st_blocks" by 2 in "du",
     and divide "f_bfree"/"f_bavail" by 512 and multiply them by
     "f_frsize" in "df".

Yes!  The smart programmer was never prevented from reporting disk
usage in consistent units, preferably kilobytes.  Even under non-SVR4,
it should have been possible for the smart programmer to figure out
just what block sizes were and to scale calculations accordingly, so
the user was always reported figures in kilobytes.

The problem, however, is, that smart programmers are few and far
between.  When they get one thing right, they get another wrong...for
example, Sun's df program is good about reporting disk usage in one
kilobyte units, but it's terrible (pre-4.1.1) about not trying to do
stats on filesystems that aren't mounted, thus causing the automounter
to go crazy, and it doesn't attempt any sort of timeout on statfs, thus
causing or a user's login session to hang if a server isn't
responding.  AT&T's "df" (SVR2 and SVR3) seems to report space in units
of 512 bytes.  But give an intuitive command like "df ." and AT&T's
"df" just exits, without any error message.  These problems are not
hard-to-avoid bugs caused by somebody overlooking something subtle;
they are very obvious fundamental flaws that a little careful thinking
would completely avoid.

>The fact that POSIX seems to be tending towards making the utilities
>report in units other than kbytes is annoying, but that definitely does
>*not* make it time to add redundant fields of the sort you suggest.

Probably true...my comment was 25% sarcasm (directed at the programmers
that you said need adult supervision), 25% humor, and 50% despair at
the state of the art in UNIX implementations.
--
Rahul Dhesi <dhesi%cirrusl at oliveb.ATC.olivetti.com>
UUCP:  oliveb!cirrusl!dhesi