Re: [nfsv4] Re: [NFS-Ganesha-Devel] Clarification on delegation behavior for same-client conflicting OPEN

On Fri, Oct 31, 2025 at 7:29=E2=80=AFAM Jeff Layton <[email protected]=
t> wrote:
>
> On Thu, 2025-10-30 at 17:35 +0000, Suhas Athani via Devel wrote:
> >
> > Hello NFS community,
> >
> > We=E2=80=99re seeking clarification on server behavior for OPEN delegat=
ions when the same client issues a potentially conflicting OPEN on a file f=
or which it already holds a delegation.
> >
> > Context and RFC references
> >
> >  *
> >    RFC 8881(10.4 Open Delegation)
> >     -
> >       =E2=80=9CThere must be no current OPEN conflicting with the reque=
sted delegation.=E2=80=9D
> >     -
> >       =E2=80=9CThere should be no current delegation that conflicts wit=
h the delegation being requested.=E2=80=9D
> >
> >  *
> >    RFC 8881(10.4.1 Open Delegation and Data Caching)
> >     -
> >       For delegation handling, READs/WRITEs without OPEN are treated as=
 the functional equivalents of a corresponding type of OPEN, and the server=
 =E2=80=9Ccan use the client ID associated with the current session to dete=
rmine if the operation has been done by the holder of the delegation (in wh=
ich case, no recall is necessary) or by another client (in which case, the =
delegation must be recalled and I/O not proceed until the delegation is ret=
urned or revoked).=E2=80=9D
> >
> >  *
> >    Historical reference: RFC 5661 (obsoleted by RFC 8881) carries the s=
ame sections 10.4 and 10.4.1
> > Questions
> > 1) Same-client conflicting OPEN:
> >
> >  *
> >    If a client holds an OPEN_DELEGATE_READ on a file and then the same =
client issues an OPEN that requires write access (or otherwise conflicts), =
should the server:
> >  *
> >
> >
> >
> >
> >     -
> >       Allow the OPEN to complete immediately without recalling the dele=
gation (i.e., no recall necessary for same-client), per RFC 8881 10.4.1; or
> >
> >  *
> >    Recall the delegation anyway and delay the operation until DELEGRETU=
RN?
The only thing I'll add to what Jeff said is.. for the case of
CLAIM_DELEGATE_CUR
or CLAIM_DELEG_CUR_FH you do not want to recall and wait for a DELEGRETURN,
since these Opens need to be done before the client can DELEGRETURN.

Also, a client is being dumb if it does any Opens on the FH other than the
above 2 Claim types while it holds a Write delegation. However, I don't
the the RFC forbids it, so I'd say just do it. (A Write delegation allows
Reading/Writing, opening for any acces/deny case locally in the client.
The server recalls the write delegation when another client requests any
Open for the FH.

rick
>
> The Linux NFS server allows the open to complete, which I think has
> been the consensus around this point in earlier discussions. Basically,
> activity from the holder of a delegation is not considered
> "conflicting". That client presumably knows about any changes and can
> update its cache accordingly, so we don't need to recall the delegation
> in this case.
>
> > 2) OPEN_DELEGATE_WRITE symmetry:
> >
> >  *
> >    If a client holds an OPEN_DELEGATE_WRITE and then the same client is=
sues an OPEN that requires read access (or otherwise changes share access/d=
eny modes), should the server similarly allow the operation to proceed with=
out recall, or recall and delay?
>
> WRITE delegations should probably have been called READ_WRITE. The
> Linux NFS server and the spec treat them as a superset of a READ
> delegation. So, opening the file for READ when you hold a WRITE deleg
> is not considered conflicting activity.
>
> > 3) Any updates since RFC 5661:
> >
> >  *
> >    Are there clarifications or consensus updates in RFC 8881 (vs. RFC 5=
661) or later documents that alter expected behavior in the same-client cas=
e?
> >
> >
> > Thank you in advance for your time and insights. Looking forward to you=
r guidance and clarification on these points.
> >
> > Regards,
> > Suhas Athani
> > NFS-ganesha Team
> >
> >
> >
> >
> > _______________________________________________
> > Devel mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
>
> --
> Jeff Layton <[email protected]>
>
> _______________________________________________
> nfsv4 mailing list -- [email protected]
> To unsubscribe send an email to [email protected]