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

[Guy Harris]

>I think it's safe to say that most users who use "du" and "df" care
>about the number of kilobytes and not much about the block size.  When
>4.3BSD seemed to be standardizing on a block size of 1K in such
>reports, I was happy, especially because the existence of fragments
>meant, to those wondering about disk space wasted due to fragmentation,
>that the block size was no longer as important.
>
>Then POSIX came along, and SVR4 reared its ugly head too.  Now I'm
>really depressed.
>
>Maybe it's time for a new field in the stat struct called something
>like st_kbytes, and fields in the statfs struct called something like
>f_kbfree and f_kbavail.

I don't see how what you're complaining about, namely the behavior of
the "du" and "df" *utilities*, would at all call for new fields in the
aforementioned structures.  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".  "st_blocks" is specified as being
in units of 1/2K, and "f_bfree"/"f_bavail" are specified as being in
units of "f_frsize".

In fact, S5R4 makes things *better*, in some ways, at the programmer's
level; it nails down what those units are, instead of just waving its
hands.

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.  Any
programmer with such rigid thought patterns that they're *obliged* to
make those programs report in units other than kbytes, just because the
calls the program uses to *retrieve* that information report in units
other than kbytes, requires adult supervision....