On Thu, Mar 11, 2010 at 09:02:55AM +0800, Mi Jinlong wrote: > > J. Bruce Fields : > > On Wed, Mar 10, 2010 at 06:22:35PM +0800, Mi Jinlong wrote: > >> Hi, > >> > >> When using command "service nfslock stop" and "service nfsklock start" > >> to restart the nfslock service at RHEL with kernel 2.6.31, if start the service > >> after stop it more than the grace_period time, lock which lockd get before > >> cann't be reclaimed for the grace_period is timeout. > >> > >> So, IMO, the lockd should get into grace_period when statd start not stop? > > > > Sorry, I'm not sure I understand. > > > > Are you saying that lockd's grace period starts when the last lock is > > shut down, instead of when the new lockd is started? That would be a > > bug, I agree. > > I means that using command "service nfslock stop" to stop the nfslock service > at RHEL, it only case statd stop, but lockd is still running. > > When statd stop, it send a KILL signal to lockd, lockd will release all locks > and get into grace_period state to wait reclaimed lock request. It means lockd > get into grace_period state when statd stop. > > But the reclaimed lock request only be caused when client receive a SM_NOTIFY > which is send by server's statd at start. If statd start when lockd isn't at > grace_period state, the reclaimed lock cann't be reclaimed. > > So, I think, lockd should get into grace_period state when statd start, not stop. > > > > > But are you really shutting down lockd completely? > > Lockd don't shut down when nfslock service stop, the service stop only case lockd stop > at RHEL. OK, so that's the problem. Lockd doesn't shut down completely, if I remember correctly, until nfsd server and all clients do. Our current NFS implementation just isn't designed to be able to shut down some components while leaving others running. Is there some reason you *need* to do what you're doing? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html