I-nodes locked ``forever''

[lrr at princeton.UUCP]

Princeton University is running Mt. Xinu's 4.3BSD with NFS on a VAX-8600
with 28Mb of memory.  The VAX operates at the `home server' for a network of
SUN Microsystems 3/50s with a 3/180 file server.  All works well, except:

Occasionally, sometimes twice in one day, sometimes not for a few weeks, we
run into a condition where the system locks because a process, usually
sendmail, has /usr/spool/mqueue locked and also /usr/spool. (These are
separate but not exported file systems.)  How can this happen, as inode
manipulation should be an autonomous operation.  We have turned on the
ITRACE code in the kernel and fixed it to work correctly (it's wrong in SUN
3.0 too - fixes available on request - there easy) and also added code from
ULTRIX 1.2 that records inode lockers and unlockers.

Has anyone else seen such a problem, and if so, how did you handle it?
We suspect a race condition which allows a process to continue even though
it has an inode locked.  Much thanks.  We haven't much hair left to pull out.

Larry Rogers
Princeton University
Department of Computer Science
Engineering Quadrangle Building, Room C334
Princeton, NJ 08544

UUCP:	princeton!lrr
CSNET:	lrr%princeton at CSnet-relay
PHONE:	609 452 6483