Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!mit-eddie!uw-beaver!cornell!gvax!jqj
From: jqj@gvax.cs.cornell.edu (J Q Johnson)
Newsgroups: comp.unix.wizards
Subject: Size of NFS "block" (was Size of SysV "block")
Message-ID: <931@gvax.cs.cornell.edu>
Date: Wed, 15-Jul-87 16:27:32 EDT
Article-I.D.: gvax.931
Posted: Wed Jul 15 16:27:32 1987
Date-Received: Fri, 17-Jul-87 07:36:20 EDT
References: <218@astra.necisa.oz> <142700010@tiger.UUCP> <52@spar.SPAR.SLB.COM>
Reply-To: jqj@gvax.cs.cornell.edu (J Q Johnson)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 14

Keywords:


Note that varying block sizes is particularly a problem in an NFS environment.
When I do a "du", it reports sizes in blocks derived from a stat of the file
(the st_blocks field).  Unfortunately, there is no easy way for du to know
what the blocksize is (the st_blksize field is "suggested" transfer size
by definition).  As a result, du gives the wrong information when applied to
a remotely mounted NFS file system if that remote system uses a different
blocking factor from what the local system expects (e.g. at Cornell, Gould
vs. SUN).

Since it is clearly inappropriate for du to do a statfs for each directory
it looks at, and since checking st_dev for changes is a rather unreliable
way to find out when you've crossed filesystem boundaries, I would recommend
that the stat structure be extended on NFS systems with a field that tells
the user what blocksize the st_blocks parameter of a stat is measured in.