Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done before/after Reclaim_complete?

[David Noveck <[e-mail]>]

>
>
> I have assumed that Open/Claim_delegate_prev will only be used by a
> client after it has rebooted.


That makes sense.


> I cannot see it being
> any more/less useful for recovery from network partitioning than the
> rest of the Opens.
>

I don't think it is useful at all in the case of network partitioning.  It
wasn't intended for that even though there is some text in the section on
delegation recovery. that mentions detecting the need for recovery as
preceding from a partition and not mentioning client restart as it should.
That needs to be cleaned up in -04.


> I assume that a server will reply to an Open/Claim_delegate_prev with
> NFS4ERR_EXPIRED if it does not have such a
> delegation for the client, since it was not able to recall it.
> I'm not sure if the spec states that, but since delegations are
> covered by the lease, it makes
> sense to me?
>

Not to me.  I would prefer NFS4ERR_RECLAIM_BAD and -04 will say that, but
we can discuss that as part of the rfc5661bis review process.

No doubt network partitioning and NFS4ERR_EXPIRED is ugly.


I agree that network partitioning is ugly.

But I do
> not see anything different for CLAIM_DELEGATE_PREV
> than other open/delegation handling.


Me either.


> Typically a client mount will
> hang pretty quickly during a network partitioning, but applications
> can certainly write a lot of dirty data into a client's data cache
> before the network partitioning is noticed and a client does not
> have any good way to deal with the dirty data.
>

I think the best way is to write it to local persistent storage, as you are
exploring.  This brings us to
CLAIM_DELEGATE_PREV which certainly wouldn't be winning any v4.1 feature
beauty contests.


>
> > …. and yet the assertion of the CLAIM_DELEGATE_PREV delegation can
> trivially fail if someone has modified or deleted the file during the
> period when the client was unable to talk to the server,


The assumption here is that the client is holding a write delegation for
the file in question, so that modification cannot happen until the
delegation is successfully recalled or revoked.  As noted before, network
partitioning is UGLY.

and there is nothing in the spec that advises what to expect next.
>

I'll try to address that in -04.


> If the file has been deleted, all opens will fail (NFS4ERR_NOENT or
> NFS4ERR_STALE?).
>

Yes.


>
> If the file was modified and the client does a Claim_null open, the
> only indication
> that it has been modified is the change attribute's value, which it
> might not have kept.
> At least the open/Claim_delegate_prev fails (presumably with
> NFS4ERR_EXPIRED)
> and the client knows the file might have been modified by someone
> else. Not great,
> but I do not see how it is worse off than without Claim_delegate_prev?
>
> It's better since, without the ability to open the file, despite the
pending-recall state of the delegation, there is no way to do the cached
updates even in the more boring case in which nobody else is trying to
modify the file.

rick
>
> >
> >
> > _________________________________
> > Trond Myklebust
> > Linux NFS client maintainer, Hammerspace
> > [e-mail]
> >
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>