What, exactly, are stat.st_blocks, statfs.f_bsize?

[Root Boy Jim]

In article <147432 at pyramid.pyramid.com> sas at shadow.pyramid.com (Scott Schoenthal) writes:
>In article <BZS.91Mar3133828 at world.std.com> bzs at world.std.com (Barry Shein) writes:
>>
>There is nothing in the NFS protocol that specifies a required filesystem
>or directory block size.  The NFS statfs response returns the "fundamental"
>block size and the total and free # of blocks in the server's filesystem.

No, but there is existing practice, and there are the Connectathons
you mentioned below. Didn't you notice that your numbers were
different locally than across the network? Didn't it bother you?

>Stat doesn't say how big your block
>Some applications (e.g., OSx 'du') don't do the statfs() when calculating
># of blocks used.  If an application uses the local notion of device
>block size, block calculations will be wrong when interacting with
>a server with a different block size.

DU shouldn't use statfs. It can cross filesystems.

So what's left? Lowest common denominator, 512 byte blocks.
I would rather see 1K "Blocks" regardless of actual size.

BTW, kudos for making your sector sizes 2k and allowing 16k blocks.

>'df' does use statfs() (at least the Sun NFSSRC and OSx 'df') and ought to
>work properly.  If not, send mail to bugs at pyramid.com  If the problem
>is in our server code, it will get fixed in a timeframe relative to the
>customer severity.

DF also prints in kilobytes, as does ls, as does du, as does sum.
Here again (sum), y'all took 'blocks' literally, and print a different
result than other BSD systems.

>Pyramid has successfully participated in Sun NFS/ONC Connectathons
>for several (>5) years.

Yes, I note that you were one of the first. However, why don't
you have a lock daemon, and is your code the latest version?
-- 
		[rbj at uunet 1] stty sane
		unknown mode: sane