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

[Rainer Laatsch]

. _______________________________________________
  ...
  Has any tested openafs on sun4x_56 or sun5x_57?
  _______________________________________________

  > sun4x_56 <

After the readdir patch, an OpenAFS-1.0.2 client  is not hanging any more
in 'ls' for a big AFS directory on this machine type :
	SunOS 5.6 Generic_105181-23 sun4m sparc SUNW,SPARCstation-5

  > sun4x_58 <

This type of OpenAFS-1.0.2 VL + file server previously was hanging with 'ls'
in a big AFS directory:
	SunOS 5.8 Generic_108528-04 sun4m sparc SUNW,SPARCstation-20
, allocating all swap space (took some time). Finally returned something
like 'resource not available'.
The server part did already function well.

After a crash, its /vicepa did not mount. So I compiled the vfsck for 
sun4x_58  which did recover it well.

Another compilation with your readdir patch applied just finished. Now doing an 
'ls /afs' , I can see 160+ entries on above machine. Fine.

So, sun4x_57 presumably is no problem any more.

Thanks a lot to you for finding out the reason!

Best regards,
Rainer Laatsch					Laatsch@rrz.Uni-Koeln.DE

PS. We use the following text of your patch for readdir (no #if 0):

*** openafs-1.0.2.old/src/afs/VNOPS/afs_vnop_readdir.c	Thu Feb  1 16:10:03 2001
--- openafs-1.0.2/src/afs/VNOPS/afs_vnop_readdir.c	Thu Feb  1 16:09:19 2001
***************
*** 641,651 ****
  		}
  #else /* AFS_HPUX_ENV */
  		code = afs_readdir_move(ode, avc, auio, o_slen,
- #if defined(AFS_SUN5_ENV)
- 		                        len, origOffset);
- #else
  					auio->afsio_resid, origOffset);
- #endif
  #endif /* AFS_HPUX_ENV */
  		/* this next line used to be AFSVFS40 or AIX 3.1, but is
  		 * really generic */
--- 641,647 ----