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@xxxxxxxxxxxx> 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. -- 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
