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

[Rick Macklem <[e-mail]>]

On Tue, Oct 1, 2024 at 7:06 PM Rick Macklem <[e-mail]> wrote:
>
> On Tue, 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?
Oh, maybe now I understand what you are asking...
--> Should #2 upgrade the Open to r/w?
    - Then, should it only return the updated Open stateid and not issue a
      delegation OR should it ignore the
OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION
      flag and reply with both the updated Open stateid and a
delegation stateid.
OR
--> Do as above and leave the Open r/o, just returning the delegations stateid.

I think this needs to be clarified.  Hopefully Thomas can respond.

rick

> Seems fine to me.  Right now (without the delstid extension) a client can
> hold several open stateids for a file (different open_owner4's) and each of
> these has a seqid field that is incremented when additional
> Opens/Open_downgrades/Close
> are done on that stateid.  The stateid.seqid for other Opens for the same
> file are not affected.
> Similarly, issuing a delegation for the same file does not affect the
> seqid in the
> open stateids for the same file.
>
> So, why would issuing a delegation without an open stateid be any different?
>
> > It seems like that would morph the open stateid
> > for this openowner without updating the client as to the new stateid.
> I'm not sure what you are thinking of here?
> The open stateid still refers to a r/o Open and
> has nothing to do with the delegation (except they happen to refer to the
> same file).
>
> > 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 does a delegreturn, the r/o open still exists for the client
> unless/until it does a Close. (It actually could be more optimal for the
> client to retain the r/o Open, so that it does not need to re-acquire it
> before doing a Delegreturn, I think?)
>
> Now maybe I didn't understand OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION,
> but I didn't think it said anything about Opens already issued to the client?
>
> >
> > If the client already holds an open stateid, should we ignore
> > WANT_OPEN_XOR_DELEGATION?
> As I understand it, a server can always ignore the OPEN4_SHARE_WANT_xxx
> flags, but I do not see a reason for the server to choose to ignore it
> in this case?
>
> Maybe I am missing something and others can clarify it, rick
>
> > --
> > Jeff Layton <[e-mail]>
> >
> > _______________________________________________
> > nfsv4 mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]