Re: [PATCH v2 0/5] nfsd: support for lifting grace period early

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

On Fri, Sep 26, 2014 at 04:37:23PM -0400, Trond Myklebust wrote:
> On Fri, Sep 26, 2014 at 3:46 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> >
> > As I understand it, the rule for the client is: you're allowed to
> > reclaim only the set locks that you held previously, where "the set of
> > locks you held previously" is "the set of locks held by the clientid
> > which last managed to send a reclaim OPEN or OPEN_CONFIRM".  So for
> > example once client1 sends that unrelated OPEN reclaim it's giving up on
> > anything else it doesn't manage to reclaim this time around.
> 
> The rule for the client is very simple: "You may attempt to reclaim
> any locks that were held immediately prior to the reboot of the
> server."
> It doesn't matter how those locks were established (ordinary OPEN,
> delegated open, reclaim open, LOCK, reclaim lock...).
> 
> However if the server reboots and the client did not manage to
> re-establish a lease (SETCLIENTID+SETCLIENTID_CONFIRM and/or
> EXCHANGE_ID+CREATE_SESSION) before the second reboot, then it is the
> server's responsibility to block that client from reclaiming any
> locks, since the client has no way to know how many times the server
> has rebooted.
> Ditto, of course, if the client tries to reclaim any locks outside the
> grace period and the server isn't tracking whether or not those locks
> have been handed out to another client.

Agreed with everything except:

	(SETCLIENTID+SETCLIENTID_CONFIRM and/or
	EXCHANGE_ID+CREATE_SESSION)

If I remember correctly: RFC 5661 says the point where this happens is
actually RECLAIM_COMPLETE.  RFC 3530 was more vague but suggested first
OPEN reclaim or OPEN_CONFIRM, and 3530bis makes that explicit.

But the client can choose an earlier point without violating the
protocol--it means it will decline reclaiming some things it could have,
but that's safer than the reverse mistake.

--b.