Xref: utzoo comp.sys.hp:6394 comp.unix.internals:479 comp.protocols.nfs:1317 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pilchuck!pacer!davidb From: davidb@Pacer.UUCP (David Barts) Newsgroups: comp.sys.hp,comp.unix.internals,comp.protocols.nfs Subject: du(1) returns funny sizes Keywords: HP9000 Solbourne NFS du Message-ID: <383@pacer.UUCP> Date: 4 Oct 90 00:06:17 GMT Followup-To: poster Organization: Pacer Corp., Bothell, WA Lines: 43 We have two systems, a Solbourne 4/600 (rabbit) and an HP9000/370 (pacer). Both systems have each other's filesystems mounted via NFS. Yesterday, I noticed that du(1) was reporting funny values when run on a remote directory. For example (this is a directory on the HP): rabbit% /usr/5bin/du /d0/users/davidb/misc 1417 /d0/users/davidb/misc pacer% du /d0/users/davidb/misc 2834 /d0/users/davidb/misc As you can see, running du on the remote system reports only half as many blocks as there really are. The reverse is true if we run du on a Solbourne directory--du reports the correct number of blocks on the Solbourne, but reports twice as many as there really are when run from the HP. This looks like a du bug (or feature :-) ), because only du is affected. Some experimenting with trace(1) on the Solbourne shows that du apparently calculates disk usage by doing an lstat(2) of everything in the directory tree, and totaling up st_size. Experimentation shows lstat(2) always returns the same values for the same file *, regardless of what system the lstat() call is issued from or where the lstat()ed file resides. If it were an NFS configuration problem, one would expect lstat(2) to report bogus sizes and everything that calls lstat() would be affected. This is why it looks like a du bug to me. * Except for st_dev (which is to be expected). The Solbourne is running OS/MP 4.0C_Export; the HP is running HP-UX 6.5. All filesystems on the HP are long file name (BSD-style) format. Even though I just noticed the problem yesterday, I believe it has been with us all along and nobody has notived it until now. Reply to me and I will summarize... -- David Barts Pacer Corporation, Bothell, WA davidb@pacer.uucp ...!uunet!pilchuck!pacer!davidb