GNU bug report logs - #11316
coreutils 8.16: du

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11316 in the body.
You can then email your comments to 11316 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: <andreas.quitzow <at> lhsystems.com>
To: <bug-coreutils <at> gnu.org>
Subject: coreutils 8.16: du
Date: Mon, 23 Apr 2012 17:09:23 +0200

[Message part 1 (text/plain, inline)]

Hello all,



I've seen a problem with the /usr/local/coreutils/bin/du command (coreutils 8.16) on our HP-UX 11.31 Itanium 2.



-          For local volumes it shows the same size as /usr/bin/du



-          For volumes mounted from Oracle-Solaris NFS servers it also shows the same size as /usr/bin/du



-          But for volumes NFS-mounted from HP-UX 11.31 NFS-Servers it shows only half the size of /usr/bin/du,
where /usr/bin/du is correct.



# cd /some/HP-UX/NFS/volume

# /usr/local/coreutils/bin/du  -sk .

1990683 .

# /usr/bin/du -sk .

3980468 .

#



Has this already been reported?



The installed NFS-Version on HP-UX NFS-server and -client is:

# swlist -l product | grep -i nfs

  NFS                   B.11.31.12     ONC/NFS; Network-File System,Information Services,Utilities



regards





Andreas Quitzow

Servermanagement UNIX

HAM AB/M-IH

Lufthansa Systems AG

Weg beim Jäger 193

D-22335 Hamburg



Phone: +49 (0) 40 5070 8496

Fax: +49 (0) 40 5070 63535

E-Mail: mailto:Andreas.Quitzow <at> lhsystems.com <mailto:Andreas.Quitzow <at> lhsystems.com>

Internet: http://www.lhsystems.com <http://www.lhsystems.com/>




Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Aktiengesellschaft, Kelsterbach, Registereintragung / Registration: Amtsgericht Darmstadt 84307
Vorsitzender des Aufsichtsrats / Chairman of the Supervisory Board: Stephan Gemkow
Vorstand / Executive Board: Stefan Hansen (Vorsitzender / Chairman), Dr. Gunter Kuechler
 

[Message part 2 (text/html, inline)]

Message #8 received at 11316 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: andreas.quitzow <at> lhsystems.com
Cc: 11316 <at> debbugs.gnu.org
Subject: Re: bug#11316: coreutils 8.16: du
Date: Mon, 23 Apr 2012 10:14:21 -0700

On 04/23/2012 08:09 AM, andreas.quitzow <at> lhsystems.com wrote:
> for volumes NFS-mounted from HP-UX 11.31 NFS-Servers it shows only half the size of /usr/bin/du,
> where /usr/bin/du is correct.

HP-UX has long had problems with 'du', as described in the
coreutils manual.  But this particular bug is new.

Can you tell us which system calls coreutils 'du' are
invoking, and which that HP-UX 'du' are invoking, by
using the 'tusc' tool of HP-UX?  That might help us
isolate the problem.

Here's where I found a download for 'tusc':

http://h21007.www2.hp.com/portal/site/dspp/PAGE.template/page.document?ciid=61086d6e1de021106d6e1de02110275d6e10RCRD

http://hpux.connect.org.uk/hppd/cgi-bin/search?package=&term=/tusc

Message #11 received at 11316 <at> debbugs.gnu.org (full text, mbox):

From: <andreas.quitzow <at> lhsystems.com>
To: <eggert <at> cs.ucla.edu>
Cc: 11316 <at> debbugs.gnu.org
Subject: RE: bug#11316: coreutils 8.16: du
Date: Tue, 24 Apr 2012 10:59:00 +0200

[Message part 1 (text/plain, inline)]

Hello Paul,



to make tusc-output a little more readable I removed all the syscalls
around lib-loading and gave "du" only a single file:

# ls -als inspection_item.lst

1282246 -rw-r-----   1 xxx      xxx        1312994526 Apr 24 01:07
inspection_item.lst



As you can see, HP-UX ls -s outputs 1k blocks while Files on Solaris
NFS-Servers and Files on local Volumes are reported in 512 Byte blocks.



the HP-UX /usr/bin/du does the following:



# tusc -f /usr/bin/du -sk inspection_item.lst

...

open("/usr/bin/du", O_RDONLY, 0)
........................................................................
.... = 3

... (libs read)

open("/usr/lib/hpux32/libc.so.1", O_RDONLY, 0)
.............................................................. = 3

open("/usr/lib/hpux32/libdl.so.1", O_RDONLY, 0)
............................................................. = 3

...

lstat64("inspection_item.lst", 0x40010e40)
.................................................................. = 0

sysfs(GETFSTYP, 0xa, 0x7ffff180)
........................................................................
.... = 0

sysfs(GETFSIND, 0x40010400, 0x288)
........................................................................
.. = 1

sysconf(_SC_CPU_VERSION)
........................................................................
............ = 768

brk(0x400112d0)
........................................................................
..................... = 0

brk(0x400132c0)
........................................................................
..................... = 0

brk(0x40016000)
........................................................................
..................... = 0

ioctl(1, TCGETA, 0x7ffff150)
........................................................................
........ = 0

1282222

write(1, "1 2 8 2 2 2 2 ", 7)
........................................................................
....... = 7

        inspection_item.lst

write(1, "\ti n s p e c t i o n _ i t e m ".., 20)
.......................................................... = 20



write(1, "\n", 1)
........................................................................
................... = 1

exit(0)
........................................................................
............................. WIFEXITED(0)



the du on Solaris does "fstatat64()" and afterwards "pathconf(filename,
_PC_XATTR_EXISTS)" to find out more, to return the correct values.



the coreutils-du does:



# tusc -f /usr/local/coreutils/bin/du -sk inspection_item.lst

...

open("/usr/local/coreutils/bin/du", O_RDONLY, 0)
............................................................ = 3

... (libs read)

open("/usr/local/lib/hpux32/libintl.so", O_RDONLY, 0)
....................................................... = 3

open("/usr/local/lib/hpux32/libiconv.so", O_RDONLY, 0)
...................................................... = 3

open("/usr/lib/hpux32/libsec.so.1", O_RDONLY, 0)
............................................................ = 3

open("/usr/lib/hpux32/libc.so.1", O_RDONLY, 0)
.............................................................. = 3

open("/usr/local/lib/hpux32/libiconv.so", O_RDONLY, 0)
...................................................... = 3

open("/usr/lib/hpux32/libm.so.1", O_RDONLY, 0)
.............................................................. = 3

open("/usr/lib/hpux32/libdl.so.1", O_RDONLY, 0)
............................................................. = 3

...

sysconf(_SC_CPU_VERSION)
........................................................................
............ = 768

...

open("/usr/lib/nls/loc/hpux32/locales.3/C", O_RDONLY, 0)
.................................................... ERR#2 ENOENT

...

open(".", O_RDONLY|0x800, 0)
........................................................................
........ = 3

...

lstat64("inspection_item.lst", 0x40021b70)
.................................................................. = 0

brk(0x40030000)
........................................................................
..................... = 0

brk(0x40032000)
........................................................................
..................... = 0

ioctl(1, TCGETA, 0x7fffefd0)
........................................................................
........ = 0

641123

write(1, "6 4 1 1 2 3 ", 6)
........................................................................
......... = 6

        inspection_item.lst

write(1, "\ti n s p e c t i o n _ i t e m ".., 21)
.......................................................... = 21

close(1)
........................................................................
............................ = 0

close(2)
........................................................................
............................ = 0

exit(0)
........................................................................
............................. WIFEXITED(0)



regards,

Andreas




Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Aktiengesellschaft, Kelsterbach, Registereintragung / Registration: Amtsgericht Darmstadt 84307
Vorsitzender des Aufsichtsrats / Chairman of the Supervisory Board: Stephan Gemkow
Vorstand / Executive Board: Stefan Hansen (Vorsitzender / Chairman), Dr. Gunter Kuechler

-----Original Message-----

From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
Sent: Monday, April 23, 2012 7:14 PM
To: QUITZOW, ANDREAS
Cc: 11316 <at> debbugs.gnu.org
Subject: Re: bug#11316: coreutils 8.16: du



On 04/23/2012 08:09 AM, andreas.quitzow <at> lhsystems.com
<mailto:andreas.quitzow <at> lhsystems.com>  wrote:

> for volumes NFS-mounted from HP-UX 11.31 NFS-Servers it shows only

> half the size of /usr/bin/du, where /usr/bin/du is correct.



HP-UX has long had problems with 'du', as described in the coreutils
manual.  But this particular bug is new.



Can you tell us which system calls coreutils 'du' are invoking, and
which that HP-UX 'du' are invoking, by using the 'tusc' tool of HP-UX?
That might help us isolate the problem.



Here's where I found a download for 'tusc':



http://h21007.www2.hp.com/portal/site/dspp/PAGE.template/page.document?c
iid=61086d6e1de021106d6e1de02110275d6e10RCRD
<http://h21007.www2.hp.com/portal/site/dspp/PAGE.template/page.document?
ciid=61086d6e1de021106d6e1de02110275d6e10RCRD>



http://hpux.connect.org.uk/hppd/cgi-bin/search?package=&term=/tusc
<http://hpux.connect.org.uk/hppd/cgi-bin/search?package=&term=/tusc>

[Message part 2 (text/html, inline)]

Message #14 received at 11316 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: andreas.quitzow <at> lhsystems.com
Cc: eggert <at> cs.ucla.edu, 11316 <at> debbugs.gnu.org
Subject: Re: bug#11316: coreutils 8.16: du
Date: Tue, 24 Apr 2012 10:06:52 +0100

On 04/24/2012 09:59 AM, andreas.quitzow <at> lhsystems.com wrote:
> Hello Paul,
> 
>  
> 
> to make tusc-output a little more readable I removed all the syscalls
> around lib-loading and gave "du" only a single file:
> 
> # ls -als inspection_item.lst
> 
> 1282246 -rw-r-----   1 xxx      xxx        1312994526 Apr 24 01:07
> inspection_item.lst
> 
>  
> 
> As you can see, HP-UX ls -s outputs 1k blocks while Files on Solaris
> NFS-Servers and Files on local Volumes are reported in 512 Byte blocks.

Could be related to this comment:

/* HP-UX counts st_blocks in 1024-byte units.
   This loses when mixing HP-UX and BSD file systems with NFS.  */

at:

http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/stat-size.h;hb=HEAD#l82

cheers,
Pádraig.

Message #17 received at 11316 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: andreas.quitzow <at> lhsystems.com
Cc: 11316 <at> debbugs.gnu.org
Subject: Re: bug#11316: coreutils 8.16: du
Date: Tue, 24 Apr 2012 22:12:17 -0700

Sorry, it looks like this will have to be debugged
by someone who has debugging tools on HP-UX; I'm
afraid that I can't do this long distance.

Message #22 received at 11316 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 11316 <at> debbugs.gnu.org
Subject: Re: bug#11316: coreutils 8.16: du
Date: Tue, 23 Oct 2018 15:51:10 -0600

close 11316
stop

(triaging old bugs)

On 24/04/12 11:12 PM, Paul Eggert wrote:
> Sorry, it looks like this will have to be debugged
> by someone who has debugging tools on HP-UX; I'm
> afraid that I can't do this long distance.
> 

With no further follow-ups in 6 years, I'm closing this bug.

-assaf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.