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 15:25:12 -0400
Trond Myklebust <trond.myklebust@primarydata.com> wrote:

> On Sat, Sep 27, 2014 at 2:40 PM, Jeff Layton
> <jeff.layton@primarydata.com> wrote:
> > 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.
> 
> So now, what if the following scenario:
> 
>                                        Server
>                                        ======
>                                        boot (B1')
> Client
> ======
> EXCHANGE_ID
> CREATE_SESSION
> OPEN(reclaim)
> LOCK(reclaim)
> RECLAIM_COMPLETE
>                                        (lift GRACE period (G1))
>                                        reboot (B2')
> EXCHANGE_ID
> CREATE_SESSION
> OPEN(reclaim)
>                                        (lift GRACE period (G2))
>                                        reboot (B3')
> EXCHANGE_ID
> CREATE_SESSION
> OPEN(reclaim)
> 
> What should happen to the OPEN(reclaim) in (B3')?
> 

(Let's call the lifting of grace periods 'G1' and 'G2'...)
 
Denied.

There was no RECLAIM_COMPLETE issued between B2 and G2. It's possible
that client2 could creep in between G2 and B3 and acquire locks that
conflict with ones that were not reclaimed by client1 between B2 and
G2. So, we can't allow any reclaims for client1 after B3.

I should add a clarification here too. I'm assuming that the server in
this case just tracks the minimum required to allow state to be
reclaimed. If it (for instance) tracked on stable storage all of the
locks that it ever granted such that it knows that there were no
conflicts, then it could be more lenient about allowing client1 to
reclaim after B3.

-- 
Jeff Layton <jlayton@primarydata.com>