Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Dec 96 23:25:41 +0000
To:        list:;
Cc:        "Ron G. Minnich" <rminnich@Sarnoff.COM>,,
Subject:   Re(2): rpc.lockd in nfs in freebsd vs. sun nfs locking
Message-ID:  <"67ad-961219232530-7084*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS>
In-Reply-To: <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
> > As late as Solaris 2.4, we were still seeing an occasional 'lock storm',
> > where RPC lock traffic would eat the wire on one particular error
> > condition that would occur when a client rebooted. This was elicited by
> > sendmail locking in /var/spool/mail. We just had a lockup the other day
> on
> > a 2.5 machine, we're not sure why but the process that was hung was ... 
> > sendmail. The guy who rebooted the machine didn't get me a core dump
> > though. 
> Certainly, when the rpc.statd notes the server death and the client
> comes back up, all clients will relock everything they had open
> (that's why NFS locking is stateful).
> When a client dies, the client doesn't have lock state and therefore
> can not reestablish locks, so that can't be the cause of your
> "lock storm" problems.

However, when the client comes up the client rpc.statd is supposed
to notify the server rpc.statd which in turn notifies the server
rpc.lockd so that it can release any locks previously held by the
server.  Of course, this shouldn't cause any further traffic unless
the server thought it had some locks on the client too (ie. both
machines were exporting FSs to each other).

Can you get a trace of the traffic on the wire when this happens?
I can't see anything in the protocol that could lead to a lock storm,
but it would be useful to understand it (if nothing else, to avoid
duplicating Solaris bugs in the FreeBSD implementation!).

Want to link to this message? Use this URL: <"67ad-961219232530-7084*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/">