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

[Scott Schoenthal]

In article <BZS.91Mar3133828 at world.std.com> bzs at world.std.com (Barry Shein) writes:
>
>>To make it worse, Pyramid's FS block sizes are 2K to 16K (yes, the
>>sectors are 2K), and so they report blocks in 2K increments. It is
>>rather sad to see filesystems quadruple in size when reported
>>between NFS partitions mounted to or from a Pyramid. Oh well...

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.

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.

>That's a real bug, I bet their NFS is based on an older LAI version.

You would lose.  OSx NFS is based upon Sun NFSSRC with multi-processor,
scaling, and "dual universe" extensions.

>There are two different values kept in the server, one for the local
>unit and another for the external unit. They're confused in a few
>places in the code, particularly in the call that does whatever it is
>that "df" wants, I forget the NFS name for this op.

'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.

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

/sas
----
Scott Schoenthal   			sas at shadow.pyramid.com
Pyramid Technology Corp.		{sun,hplabs,decwrl,uunet}!pyramid!sas