davidb@Pacer.UUCP (David Barts) (10/04/90)
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
rosl@hpuamsa.UUCP (Rob Slotemaker CRC) (10/04/90)
The program du(1) was working fine on HP-UX 6.0. In newer revisions du has been changed to use st.st_blocks to calculate the disk usage. When using du on an NFS mounted filesystem the command will report a value that is twice what it should be. I have tested it on our systems (9000/8xx and 9000/3xx both running HP-UX 7.0), but I always get the correct values. Best regards, Rob
rsh@hpfcdc.HP.COM (Scott Holbrook) (10/05/90)
> 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. Your analysis of the problem is correct. There is a known bug in the HP-UX version du(1) that has been fixed for the next major release after the 7.0 release. It sounds like the Solbourne version has the same bug too. Scott Holbrook HP-UX commands
paul@cs.edinburgh.ac.uk (Paul Anderson) (10/05/90)
I have seen this problem between Suns and a Pyramid. It seems that du works out the sizes using the st_blocks field of the stat structure, but different system have different ideas about what constitutes a "block". I have not managed to find any definitive answer to what a "block" should be - If I remember correctly, Suns assume it to 512 fixed, always, but other systems treat it as some property of the filesystem. -- Paul Anderson JANET: paul@uk.ac.ed.lfcs LFCS, Dept. of Computer Science UUCP: ..!mcvax!ukc!lfcs!paul University of Edinburgh ARPA: paul%lfcs.ed.ac.uk@nsfnet-relay.ac.uk Edinburgh EH9 3JZ, UK. Tel: 031-667-1081 Ext 2788
jns@hpuerca.HP.COM (Jeff Squires) (10/05/90)
I thought that you would like the SR number for this defect if you were tracking it in your Software Status Bulletin -- the SR # is 5000-496729. jeff squires North American Response Center Atlanta, GA HP-UX Support