Re: [nfsv4] Could somebody please enlighten me as to what is supposed to happen in this situation?

[Jeff Layton <jeff.layton@primarydata.com>]

On Sat, 27 Sep 2014 11:22:29 -0400
Trond Myklebust <trond.myklebust@primarydata.com> 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@primarydata.com>