Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: What, exactly, are stat.st_blocks, statfs.f_bsize?
Message-ID: <6558@auspex.auspex.com>
Date: 11 Mar 91 19:39:04 GMT
References: <147432@pyramid.pyramid.com>
Organization: Auspex Systems, Santa Clara
Lines: 31

>There is nothing in the NFS protocol that specifies a required filesystem
>or directory block size.

It also doesn't specify the units to be used in the "blocks" field of
the "fattr" structure in an NFS GETATTR reply; this is extremely
unfortunate, as it led various vendors not to use 512-byte chunks as the
size, and therefore cause users of programs running on other machines to be
unpleasantly surprised when said programs assume, incorrectly, that when
they do a "stat()" the "st_blocks" result isn't in units of 512-byte
chunks.

Given that S5R4 and 4.3-reno both specify, in the documentation, that
"st_blocks" is in units of 512-byte chunks, a convention needs to be
specified - either in the NFS protocol, or in some kind of side notes to
it - ensuring that (modern UNIX) clients can arrange to report
"st_blocks" in those units.

Given that most (modern UNIX) clients probably just use what they get
back from the server in the "blocks" field, the most appropriate
convention would probably be to say "'blocks' is in units of 512-byte
chunks, regardless of what the block or fragment size of the underlying
file system, or the disk block size, is."

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

*Lots* of applications on *non*-Pyramid systems don't do the "statfs()"
when calculating # of blocks used from the "st_blocks" field; I suspect,
in fact, most applications on most systems don't.