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

[Thomas Haynes <[e-mail]>]

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