Re: [PATCH v4 0/6] nfsd: overhaul the client name tracking code

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Jan 25, 2012 at 06:41:58AM -0500, Jeff Layton wrote:
> On Tue, 24 Jan 2012 18:08:55 -0500
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
> 
> > On Mon, Jan 23, 2012 at 03:01:01PM -0500, Jeff Layton wrote:
> > > This is the fourth iteration of this patchset. I had originally asked
> > > Bruce to take the last one for 3.3, but decided at the last minute to
> > > wait on it a bit. I knew there would be some changes needed in the
> > > upcall, so by waiting we can avoid needing to deal with those in code
> > > that has already shipped. I would like to see this patchset considered
> > > for 3.4 however.
> > > 
> > > The previous patchset can be viewed here. That set also contains a
> > > more comprehensive description of the rationale for this:
> > > 
> > >     http://www.spinics.net/lists/linux-nfs/msg26324.html
> > > 
> > > There have been a number of significant changes since the last set:
> > > 
> > > - the remove/expire upcall is now gone. In a clustered environment, the
> > > records would need to be refcounted in order to handle that properly. That
> > > becomes a sticky problem when you could have nodes rebooting. We don't
> > > really need to remove these records individually however. Cleaning them
> > > out only when the grace period ends should be sufficient.
> > 
> > I don't think so:
> > 
> > 	1. Client establishes state with server.
> > 	2. Network goes down.
> > 	3. A lease period passes without the client being able to renew.
> > 	   The server expires the client and grants conflicting locks to
> > 	   other clients.
> > 	3. Server reboots.
> > 	4. Network comes back up.
> > 
> > At this point, the client sees that the server has rebooted and is in
> > its grace period, and reclaims.  Ooops.
> > 
> > The server needs to be able to tell the client "nope, you're not allowed
> > to reclaim any more" at this point.
> > 
> > So we need some sort of remove/expire upcall.
> > 
> 
> Doh! I don't know what I was thinking -- you're correct and we do need
> that.
> 
> Ok, I'll see about putting it back and will resend. That does make it
> rather nasty to handle clients mounting from multiple nodes in the same
> cluster though. We'll need to come up with a data model that allows for
> that as well.

Honestly, in the v4-based migration case if one client can hold state on
mulitple nodes, and could (could it?) after reboot decide to reclaim
state on a different node from the one it previously held the same state
on--I'm not even clear what *should* happen, or if the protocol is
really adequate for that case.

--b.