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

[Jeff Layton <[e-mail]>]

On Wed, 2024-10-02 at 10:13 -0700, Thomas Haynes wrote:
> 
> > On Oct 2, 2024, at 9:15 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.
> > 
> > So yes, it is okay.
> > 
> > Let me see if I can still add this text.
> 
> 
>    Note that the OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION flag is a
>    hint.  The server might return both stateids.  Consider the scenario
>    in which the client opens a file read-only (with
>    OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION set) and gets only an
>    open stateid.  If the client then opens the file for read-write (with
>    OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION set), then the server has
>    three options:
>    
>    1.  Only an open stateid with the correct seqid.
> 
>    2.  Only a delegation stateid with the open stateid now having an
>        incorrect seqid as it needs to be upgraded.
>    
>    3.  Both an open (which will be upgraded) and a delegation stateid.
>    
>    In this scenario, returning just a delegation stateid would hide
>    information from the client.  If the client already has an open
>    stateid, then the server SHOULD ignore the
>    OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION flag and return both the
>    open and delegation stateids.
> 
> 
> Any objections to that?

Nope. That looks great. Thanks for clarifying!
-- 
Jeff Layton <[e-mail]>