On Sat, 27 Sep 2014 11:22:29 -0400 Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: My take (quite possibly wrong, but...) > The scenario is this: > Server > ====== > boot (B1) > Client > ====== > EXCHANGE_ID > CREATE_SESSION > OPEN(reclaim) > LOCK(reclaim) > RECLAIM_COMPLETE > (lift GRACE period) At this point, we'd deny reclaim from any client that has not issued a RECLAIM_COMPLETE. In the case of the Linux server with nfsdcltrack, we clean out any client records that have not issued a RECLAIM_COMPLETE. > reboot (B2) > EXCHANGE_ID > CREATE_SESSION > OPEN(reclaim) > reboot (while GRACE period > still being enforced) (B3) > EXCHANGE_ID > CREATE_SESSION > OPEN(reclaim) > > What should be the server response to the above OPEN(reclaim) from the > client after reboot (B3)? > My expectation is that it would be granted. There was a RECLAIM_COMPLETE issued during the boot where the grace period was last lifted, and that should be enough to allow the client to issue reclaims on any subsequent reboot, until the grace period is lifted again. Doing anything else would be a pretty unfriendly way for the server to behave. In the face of rapid reboots (a not-uncommon occurrence when patching, etc), you'd lose state unless the client just happened to get in there quickly enough to issue a RECLAIM_COMPLETE between each reboot. That was the situation with the legacy client tracker in knfsd. When testing, it was trivial to reboot the machine quickly twice and on the second reboot nothing could be reclaimed. -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- 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
