[OpenAFS] openafs-1.0.2 on SuperSPARC (Solaris 8 32Bit)

[Andreas Sindermann]

Hi,

after successfully compiling and installing openafs-1.0.2 on a Sun SS20
(SuperSPARC) running Solaris 8 (32Bit) an interesting problem occurs:

/bin/ls doesn't seem to work fine on AFS directories whereas calling
programs from paths within the AFS tree is no problem. A truss output
reveals the following:

17:16:23 sun20 28 >uname -a
SunOS sun20 5.8 Generic_108528-03 sun4m sparc SUNW,SPARCstation-20

17:16:32 sun20 29 >/bin/pwd
/afs/rrz.uni-koeln.de/vol/gnu/bin/sun4m_51

17:22:40 sun20 30 >truss /bin/ls
execve("/usr/bin/ls", 0xEFFFF564, 0xEFFFF56C)  argc = 1
stat("/usr/bin/ls", 0xEFFFF2B0)                 = 0

[...]

lstat64(".", 0xEFFFF408)                        = 0
open64(".", O_RDONLY|O_NDELAY)                  = 3
fcntl(3, F_SETFD, 0x00000001)                   = 0
fstat64(3, 0xEFFFF348)                          = 0
brk(0x0002EC98)                                 = 0
brk(0x00030C98)                                 = 0
getdents64(3, 0x0002EBD0, 1048)                 = 1048
brk(0x00030C98)                                 = 0
brk(0x00038C98)                                 = 0
[...continuing forever with brk() calls...]

The process size of /bin/ls (checked using 'top') is growing to
hundreds of MBs in a few seconds.



Whereas on a Solaris 7 (32Bit) system running an older 'official'
Transarc version (afs3.5 3.11) it looks like this:


17:43:40 sun80 15 >truss /bin/ls
execve("/usr/bin/ls", 0xFFBEF56C, 0xFFBEF574)  argc = 1
stat("/usr/bin/ls", 0xFFBEF260)			= 0

[...]

lstat64(".", 0xFFBEF410)			= 0
open64(".", O_RDONLY|O_NDELAY)			= 3
fcntl(3, F_SETFD, 0x00000001)			= 0
fstat64(3, 0xFFBEF350)				= 0
getdents64(3, 0x0002DAF0, 1048)			= 1048
getdents64(3, 0x0002DAF0, 1048)			= 1048
brk(0x0002E9C8)					= 0
brk(0x000389C8)					= 0
getdents64(3, 0x0002DAF0, 1048)			= 1048
getdents64(3, 0x0002DAF0, 1048)			= 1048
brk(0x000389C8)					= 0
brk(0x000409C8)					= 0
getdents64(3, 0x0002DAF0, 1048)			= 1048
getdents64(3, 0x0002DAF0, 1048)			= 1048
brk(0x000409C8)					= 0
brk(0x0004A9C8)					= 0
getdents64(3, 0x0002DAF0, 1048)			= 1048
getdents64(3, 0x0002DAF0, 1048)			= 1048
brk(0x0004A9C8)					= 0
brk(0x000549C8)					= 0
getdents64(3, 0x0002DAF0, 1048)			= 1048
brk(0x000549C8)					= 0
brk(0x0005C9C8)					= 0
getdents64(3, 0x0002DAF0, 1048)			= 1048
getdents64(3, 0x0002DAF0, 1048)			= 1048
getdents64(3, 0x0002DAF0, 1048)			= 1048
brk(0x0005C9C8)					= 0
brk(0x0005E9C8)					= 0
brk(0x0005E9C8)					= 0
brk(0x000669C8)					= 0
getdents64(3, 0x0002DAF0, 1048)			= 1048
brk(0x000669C8)					= 0
brk(0x000709C8)					= 0
getdents64(3, 0x0002DAF0, 1048)			= 1048
getdents64(3, 0x0002DAF0, 1048)			= 80
getdents64(3, 0x0002DAF0, 1048)			= 0
close(3)					= 0
ioctl(1, TCGETA, 0xFFBED52C)			= 0
write(1, " F 2 C                  ".., 45)	= 45
write(1, " U n a m e              ".., 44)	= 44
write(1, " [                      ".., 48)	= 48
write(1, " _ g s 2 . 6 1          ".., 42)	= 42
write(1, " a 2 p                  ".., 39)	= 39

[...]

write(1, " l e m a c s            ".., 44)	= 44
write(1, " l e m a c s - 1 9 . 1 0".., 42)	= 42
write(1, " l e s s                ".., 41)	= 41
llseek(0, 0, SEEK_CUR)				= 139389
_exit(0)

I.e. only a few brk() calls due to the large number of files in the
directory and some getdents64() calls for reading the dir entries.


Now to something completely different :-)

I'd like to suggest not to set the path to the compiler
/opt/SUNWspro/bin explicitely in src/config/Makefile.sun4x_5[5-8],
as  cc  might be installed in a different location (e.g. at our site
several versions of Sun Compilers are being installed in parallel). 
Just an idea...

Thanks for your patience,
Andreas

-- 
Andreas Sindermann                   fon: +49 (221) 470-4201
Institut fuer Theoretische Physik    fax: +49 (221) 470-5159
Universitaet zu Koeln
Zuelpicher Str. 77                   mailto:sinder@thp.Uni-Koeln.DE
D-50937 Koeln, Germany               http://www.thp.uni-koeln.de/~sinder