On Thu, 2018-12-20 at 13:05 -0500, J. Bruce Fields wrote: > On Thu, Dec 20, 2018 at 12:29:43PM -0500, Jeff Layton wrote: > > That wasn't my thinking here. > > > > Suppose we have a client that holds some locks. Server reboots and we do > > EXCHANGE_ID and start reclaiming, and eventually send a > > RECLAIM_COMPLETE. > > > > Now, there is a network partition and we lose contact with the server > > for more than a lease period. The client record gets tossed out. Client > > eventually reestablishes the connection before the grace period ends and > > attempts to reclaim. > > > > That reclaim should succeed, IMO, as there is no reason that it > > shouldn't. Nothing can have claimed competing state since we're still in > > the grace period. > > That scenario requires a grace period longer than the lease period, > which isn't impossible but sounds rare? I guess you're thinking in the > cluster case about the possibility of a second node failure extending > the grace period. > Isn't our grace period twice the lease period by default? I think we do have to assume that it may take an entire lease period before the client notices that the server has rebooted. If grace period == lease period then you aren't leaving much time for reclaim to occur. > Still, that's different from the case where the client explicitly > destroys its own state. That could happen in less than a lease period > and in that case there won't be a reclaim. I think that case could > happen if a client rebooted quickly or maybe just unmounted. > > Hm. > True. You're right that we don't want to delay lifting the grace period because we're waiting for clients that have unmounted and aren't coming back. Unfortunately, it's difficult to distinguish the two cases. Could we just decrement the counter when we're tearing down a clientid because of lease expiration and not on DESTROY_CLIENT? -- Jeff Layton <jlayton@xxxxxxxxxx>
