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

On Wed, 2025-11-05 at 12:18 -0800, Rick Macklem wrote:
> On Fri, Oct 31, 2025 at 7:29=E2=80=AFAM Jeff Layton <jlayton@poochiereds.=
net>
> wrote:
> >=20
> > On Thu, 2025-10-30 at 17:35 +0000, Suhas Athani via Devel wrote:
> > >=20
> > > Hello NFS community,
> > >=20
> > > We=E2=80=99re seeking clarification on server behavior for OPEN
> > > delegations when the same client issues a potentially conflicting
> > > OPEN on a file for which it already holds a delegation.
> > >=20
> > > Context and RFC references
> > >=20
> > > =C2=A0*
> > > =C2=A0=C2=A0 RFC 8881(10.4 Open Delegation)
> > > =C2=A0=C2=A0=C2=A0 -
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9CThere must be no current OPEN=
 conflicting with the
> > > requested delegation.=E2=80=9D
> > > =C2=A0=C2=A0=C2=A0 -
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9CThere should be no current de=
legation that conflicts with
> > > the delegation being requested.=E2=80=9D
> > >=20
> > > =C2=A0*
> > > =C2=A0=C2=A0 RFC 8881(10.4.1 Open Delegation and Data Caching)
> > > =C2=A0=C2=A0=C2=A0 -
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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 t=
he
> > > current session to determine if the operation has been done by
> > > the holder of the delegation (in which 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
> > > returned or revoked).=E2=80=9D
> > >=20
> > > =C2=A0*
> > > =C2=A0=C2=A0 Historical reference: RFC 5661 (obsoleted by RFC 8881) c=
arries
> > > the same sections 10.4 and 10.4.1
> > > Questions
> > > 1) Same-client conflicting OPEN:
> > >=20
> > > =C2=A0*
> > > =C2=A0=C2=A0 If a client holds an OPEN_DELEGATE_READ on a file and th=
en the
> > > same client issues an OPEN that requires write access (or
> > > otherwise conflicts), should the server:
> > > =C2=A0*
> > >=20
> > >=20
> > >=20
> > >=20
> > > =C2=A0=C2=A0=C2=A0 -
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Allow the OPEN to complete immediately=
 without recalling
> > > the delegation (i.e., no recall necessary for same-client), per
> > > RFC 8881 10.4.1; or
> > >=20
> > > =C2=A0*
> > > =C2=A0=C2=A0 Recall the delegation anyway and delay the operation unt=
il
> > > DELEGRETURN?
> 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.
>=20
> 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.

RFC8881 strongly encourages clients to send OPENs in parallel. If you
want to build servers that don't support doing so, then that is of
course your right...

--=20
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[email protected], trond.myklebust-F/[email protected]