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

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 delegatio=
ns when the same client issues a potentially conflicting=C2=A0OPEN on a fil=
e=C2=A0for which it already holds a delegation.
> =C2=A0
> Context and RFC references
>=20
> =C2=A0*=20
> =C2=A0=C2=A0=C2=A0RFC 8881(10.4 Open Delegation)
> =C2=A0=C2=A0=C2=A0=C2=A0-=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9CThere must be no current OPE=
N conflicting with the requested delegation.=E2=80=9D
> =C2=A0=C2=A0=C2=A0=C2=A0-=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9CThere should be no current d=
elegation that=C2=A0conflicts=C2=A0with the delegation being requested.=E2=
=80=9D
> =C2=A0
> =C2=A0*=20
> =C2=A0=C2=A0=C2=A0RFC 8881(10.4.1 Open Delegation and Data Caching)
> =C2=A0=C2=A0=C2=A0=C2=A0-=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0For 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=C2=A0associated=
 with the current session to determine if the operation=C2=A0has been done =
by the holder of the delegation (in which case, no recall is necessary) or =
by another client=C2=A0(in=C2=A0which case, the delegation must be recalled=
 and I/O not proceed until the delegation is returned or revoked).=E2=80=9D
> =C2=A0
> =C2=A0*=20
> =C2=A0=C2=A0=C2=A0Historical reference: RFC 5661 (obsoleted=C2=A0by=C2=A0=
RFC 8881) carries the same=C2=A0sections 10.4 and 10.4.1
> Questions=C2=A0
> 1) Same-client conflicting OPEN:
>=20
> =C2=A0*=20
> =C2=A0=C2=A0=C2=A0If a client holds an OPEN_DELEGATE_READ on a file and t=
hen the same client issues an OPEN that requires write access (or otherwise=
 conflicts), should the=C2=A0server:
> =C2=A0*=20
> =C2=A0=C2=A0=C2=A0
>=20
>=20
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0-=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Allow the OPEN to complete immediatel=
y without recalling the delegation (i.e., no recall necessary for same-clie=
nt), per RFC 8881 10.4.1; or
> =C2=A0
> =C2=A0*=20
> =C2=A0=C2=A0=C2=A0Recall the delegation anyway and delay the operation un=
til DELEGRETURN?=C2=A0

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:
>=20
> =C2=A0*=20
> =C2=A0=C2=A0=C2=A0If a client holds an OPEN_DELEGATE_WRITE and then the=
=C2=A0same client issues an=C2=A0OPEN=C2=A0that requires read access (or ot=
herwise changes share access/deny modes), should the=C2=A0server=C2=A0simil=
arly=C2=A0allow=C2=A0the=C2=A0operation to=C2=A0proceed=C2=A0without=C2=A0r=
ecall, or=C2=A0recall and=C2=A0delay?

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=C2=A0RFC=C2=A05661:
>=20
> =C2=A0*=20
> =C2=A0=C2=A0=C2=A0Are there=C2=A0clarifications=C2=A0or consensus updates=
=C2=A0in=C2=A0RFC=C2=A08881 (vs. RFC=C2=A05661) or=C2=A0later documents tha=
t=C2=A0alter expected behavior=C2=A0in the=C2=A0same-client case?
>=20
>=20
> Thank you in advance for your time and insights. Looking forward to your =
guidance and clarification on these points.
>=20
> Regards,
> Suhas Athani
> NFS-ganesha Team
>=20
>=20
>=20
>=20
> _______________________________________________
> Devel mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

--=20
Jeff Layton <[email protected]>