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.