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

[Rick Macklem <[e-mail]>]

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??)

rick

>
> --
> Jeff Layton <[e-mail]>