The system worked very well under extreme load for about 24 hours.

Then things started to go bad and finally:

panic: ffs_valloc: dup alloc

_Debugger(....)
_panic(....)
_ffs_valloc(f3b1b4c) + fc
_ufs_mkdir(f3b1bc4) + 7e
_nfsrv_mkdir(e612900,e58d300,e5f8c00,f3b1e0c) + 9aa
_nfssvc_nfsd(f3b1e58,15e08,e5f8c00,0,96) + 428
_sys_nfssvc(e5f8c00,f3b1f84,f3b1f7c) + 49c
_syscall(9b) + 184
_trap0() + e

[BTW it would be *really* nice to have a quick macro in the debugger to
clear all the background colour planes on the console so you don't have
to read the debugger output through the dregs of a dead X11 screen!]

The mkdir was probably from a script that was (is -- it restarted after
the reboot!) on a diskless client of this machine:

	while : ; do
		find . -depth -print | cpio -pdmuv /var/tmp/foo
		rm -rf /var/tmp/foo
	done

There was a similar script running on the server too, and the server was
also running many other torturous processes to force it to continually
page and swap.

The fsck after reboot found several DUP inode uses and required several
manual fsck's to fix completely.

Most notably there were two "zero length directories" in the area where
cpio was creating the new hierarchy, probably as a result of the two
cpio's colliding.

I'd guess there's some mutual interlocking not happening between local
and NFS filesystem access.  This may or may not have been complicated
somewhat by the high level of VM paging and swapping.

Something's not quite ready for true production use yet....

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>