[nfsv4] Re: OPEN_XOR_DELEGATION when there is existing OPEN stateid

[Rick Macklem <[e-mail]>]

On Thu, Oct 3, 2024 at 10:00 AM Thomas Haynes <[e-mail]> wrote:
>
>
>
> On Oct 3, 2024, at 8:12 AM, Rick Macklem <[e-mail]> wrote:
>
> On Thu, Oct 3, 2024 at 7:32 AM Rick Macklem <[e-mail]> wrote:
>
>
> On Thu, Oct 3, 2024 at 3:21 AM Jeff Layton <[e-mail]> wrote:
>
>
> On Wed, 2024-10-02 at 17:26 -0700, Rick Macklem wrote:
>
> On Wed, Oct 2, 2024 at 9:16 AM Thomas Haynes <[e-mail]> wrote:
>
>
>
>
> On Oct 2, 2024, at 5:51 AM, Jeff Layton <[e-mail]> wrote:
>
> On Tue, 2024-10-01 at 22:24 -0700, Thomas Haynes wrote:
>
>
> On Oct 1, 2024, at 6:11 AM, Jeff Layton <[e-mail]> wrote:
>
> Another delstid question. Consider the following situation. All opens
> have WANT_OPEN_XOR_DELEGATION set:
>
> 1/ Client opens a file r/o. Server doesn't assign a delegation, so an
> open stateid (with seq=1) is returned.
>
> 2/ Client opens the file again for r/w. Server assigns a delegation and
> skips updating the OPEN stateid's seqid and sending the result back to
> the client.
>
> Is that wrong behavior? It seems like that would morph the open stateid
> for this openowner without updating the client as to the new stateid.
> The delegation does cover it in that case, but it seems less than
> optimal if the client ends up returning that delegation later.
>
> If the client already holds an open stateid, should we ignore
> WANT_OPEN_XOR_DELEGATION?
> --
> Jeff Layton <[e-mail]>
>
>
>
> It seems to me we can’t break the upgrade, so we have to honor the WANT_OPEN_XOR_DELEGATION by returning an upgraded open stateid.
>
> I.e., if the client already has an open stateid and presents an WANT_OPEN_XOR_DELEGATION, then cannot return just a delegation. Either we just upgrade the existing open stateid or we upgrade it and also return the delegation.
>
> Likewise, if we had already returned a delegation stateid, we should just return a delegation stateid.
>
> Feel free to argue with me ….
>
>
> No, that makes sense I think.
>
> Would it be OK to just ignore WANT_OPEN_XOR_DELEGATION in this case,
> and return both an updated open stateid and the delegation stateid?
> That's probably the more desirable outcome (regardless of the "XOR" in
> the name).
> --
> Jeff Layton <[e-mail]>
>
>
>
> It is a hint, none of the language states it MUST return one or the other.
>
> The only bother is that you have to provide a reason for ignoring it.
> Having said that, I doubt clients care what the reason is and I'll
> note that a client is being "dumb" if it uses the
> OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION flag
> in this case.
>
>
> Do we need to provide a reason? I think we can just ignore this flag
> and send both stateids in this case. We're not denying the delegation,
> so there is no need to send a WND4_* status code.
>
> Oops, yes, you are correct. If you are replying with a delegation, you
> don't need a "why I didn't" flag.  I was thinking that these had to be returned
> whenever you ignored a WANT flag, but that is not what the RFC says.
> (I now need to check the FreeBSD server to make sure I got that correct
> when I implemented it.)
>
> However, for a typical XOR case (where the client does not have an Open
> already) and choosing to not issue the delegation...
> --> It is not 100% obvious if a WND4_* flag is required in the reply?
> (I would say it is not required, because the server is satisfying the
> request, but??)
>
> Hmm. Here's what RFC8881 says:
>
>   If the server supports the new _WANT_ flags and the client sends one
>   or more of the new flags, then in the event the server does not
>   return a delegation, it MUST return a delegation type of
>   OPEN_DELEGATE_NONE_EXT.  The field ond_why in the reply indicates why
>   no delegation was returned and will be one of:
>
> It sounds like it is clear, in that a WND4_* reply flag is needed if an Open
> with OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION does not
> get a delegation in the reply.
>
> This brings me to something else that is not explicit in the draft...
> --> OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION only seems
>      meaningful when it is combined with one of the other
>      OPEN_SHARE_ACCESS_WANT_xxx flags.
> Is this correct? Should this be explicit in the draft?
>
>
> I was going to say yes, but now I believe not after reading RFC8881:
>
>    If (share_access & OPEN4_SHARE_ACCESS_WANT_DELEG_MASK) is not zero,
>    then the client will have specified one and only one of:
>
>    OPEN4_SHARE_ACCESS_WANT_READ_DELEG
>
>    OPEN4_SHARE_ACCESS_WANT_WRITE_DELEG
>
>    OPEN4_SHARE_ACCESS_WANT_ANY_DELEG
>
>    OPEN4_SHARE_ACCESS_WANT_NO_DELEG
>
>    OPEN4_SHARE_ACCESS_WANT_CANCEL
>
>    Otherwise, the client is neither indicating a desire nor a non-desire
>    for a delegation, and the server MAY or MAY not return a delegation
>    in the OPEN response.
>
> I.e., if I set only OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION, I am saying that I don’t care if you assign me a delegation, but if you do, only assign me one of a delegation or open stateid.
Ok, I didn't notice that OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION
was not in OPEN4_SHARE_ACCESS_WANT_DELEG_MASK, so I suppose the above
is correct.

Btw, the draft has this...

const OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION = 0x200000;

which appears to be a typo, since
OPEN4_SHARE_ACCESS_WANT_PUSH_DELEG_WHEN_UNCONTENDED
is defined as the same value in RFC8881.

rick


>
> Thoughts?
>
>
>
>
> rick
>
>
> rick
>
>
> --
> Jeff Layton <[e-mail]>
>
>