davidb@Pacer.UUCP (David Barts) (10/05/90)
(If you haven't responded to my first post about du, please READ THIS FIRST. Thanks.) Several people have already responded to my question on du(1) reporting erroneous information (off by a factor of 2) when run on a remote disk. Most responses have been of the variety "du on the HP reports usage in 512 byte blocks, while du in the Solbourne reports in kbytes." This can NOT be the case, since I was running /usr/5bin/du (the System V du, *not* BSD du) on the Solbourne. Both du's correctly report size in 512 kb blocks on local filesystems and goof up on remote ones. Two people wrote about the system block sizes being different and this being the cause of my problem. At first I doubted this, because both systems run the Berkeley fast file system and have a block size of 8k, right? Apparently, st_blocks reports the size in a number of blocks, where one block is contains DEV_BSIZE bytes (defined in <sys/param.h>). DEV_BSIZE (512 bytes on the Solbourne, 1024 on the HP) is different on both systems. This blocksize ends up embedded in du, and each system's du thinks that the entire world uses the same size it does. In summary, avoid using du on network directories--it does not give reliable information. -- David Barts Pacer Corporation, Bothell, WA davidb@pacer.uucp ...!uunet!pilchuck!pacer!davidb
chip@chinacat.Unicom.COM (Chip Rosenthal) (10/05/90)
In article <384@pacer.UUCP> davidb@Pacer.UUCP (David Barts) writes: >Followup-To: poster feych >This blocksize ends up embedded in du, and each system's du thinks that >the entire world uses the same size it does. In summary, avoid using >du on network directories--it does not give reliable information. Then the du is broke...which doesn't surprise me. I found several broken du's when testing the one I posted recently to comp.sources.misc. The tests were not run in networked environments - the problem was usually seen as botched double and triple indirection calculations. If your remote filesystem properly supports the statfs() system call then the du I posted will work since it uses statfs() to determine the filesystem block size. So, I'd expect it to be well behaved in most SysVish environments, even networked ones. -- Chip Rosenthal <chip@chinacat.Unicom.COM> Unicom Systems Development, 512-482-8260 Our motto is: We never say, "But it works with DOS."
bzs@world.std.com (Barry Shein) (10/05/90)
I ran into this problem when doing a port of Lachman's NFS years ago.
My guess is that the system being talked about is using a very old
(like 1986-7) version of Lachman's NFS which still has this bug. It
returned the local rather than "nfs" value in the statfs() call.
Trivial fix, it just grabbed the wrong struct element.
Nothing anyone can do if vendors ship ancient software.
--
-Barry Shein
Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD