9:29 a.m.
On Thu, 2025-10-30 at 17:35 +0000, Suhas Athani via Devel wrote:
Hello NFS community,
We’re 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.
Context and RFC references
*
RFC 8881(10.4 Open Delegation)
-
“There must be no current OPEN conflicting with the requested delegation.”
-
“There should be no current delegation that conflicts with the delegation being
requested.”
*
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 “can use the client
ID associated with the 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).”
*
Historical reference: RFC 5661 (obsoleted by RFC 8881) carries the same 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 delegation (i.e., no
recall necessary for same-client), per RFC 8881 10.4.1; or
*
Recall the delegation anyway and delay the operation until DELEGRETURN?
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 issues an OPEN that
requires read access (or otherwise changes share access/deny modes), should
the server similarly allow the operation to proceed without 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 5661) or later
documents that alter expected behavior in the same-client case?
Thank you in advance for your time and insights. Looking forward to your guidance and
clarification on these points.
Regards,
Suhas Athani
NFS-ganesha Team
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
--
Jeff Layton <jlayton(a)poochiereds.net>
2:18 p.m.
New subject: [nfsv4] Re: Clarification on delegation behavior for same-client conflicting OPEN
On Fri, Oct 31, 2025 at 7:29 AM Jeff Layton <jlayton(a)poochiereds.net> wrote:
On Thu, 2025-10-30 at 17:35 +0000, Suhas Athani via Devel wrote:
>
> Hello NFS community,
>
> We’re 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.
>
> Context and RFC references
>
> *
> RFC 8881(10.4 Open Delegation)
> -
> “There must be no current OPEN conflicting with the requested delegation.”
> -
> “There should be no current delegation that conflicts with the delegation
being requested.”
>
> *
> 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 “can use the client
ID associated with the 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).”
>
> *
> Historical reference: RFC 5661 (obsoleted by RFC 8881) carries the same 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 delegation (i.e.,
no recall necessary for same-client), per RFC 8881 10.4.1; or
>
> *
> Recall the delegation anyway and delay the operation until 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.
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 issues an
OPEN that requires read access (or otherwise changes share access/deny modes), should the
server similarly allow the operation to proceed without 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 5661) or
later documents that alter expected behavior in the same-client case?
> >
> >
> > Thank you in advance for your time and insights. Looking forward to your
guidance and clarification on these points.
> >
> > Regards,
> > Suhas Athani
> > NFS-ganesha Team
> >
> >
> >
> >
> > _______________________________________________
> > Devel mailing list -- devel(a)lists.nfs-ganesha.org
> > To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
>
> --
> Jeff Layton <jlayton(a)poochiereds.net>
>
> _______________________________________________
> nfsv4 mailing list -- nfsv4(a)ietf.org
> To unsubscribe send an email to nfsv4-leave(a)ietf.org
2:31 p.m.
New subject: [nfsv4] Re: 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 AM Jeff Layton
<jlayton(a)poochiereds.net>
wrote:
>
> On Thu, 2025-10-30 at 17:35 +0000, Suhas Athani via Devel wrote:
> >
> > Hello NFS community,
> >
> > We’re 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.
> >
> > Context and RFC references
> >
> > *
> > RFC 8881(10.4 Open Delegation)
> > -
> > “There must be no current OPEN conflicting with the
> > requested delegation.”
> > -
> > “There should be no current delegation that conflicts with
> > the delegation being requested.”
> >
> > *
> > 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 “can use the client ID associated with the
> > 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).”
> >
> > *
> > Historical reference: RFC 5661 (obsoleted by RFC 8881) carries
> > the same 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 delegation (i.e., no recall necessary for same-client), per
> > RFC 8881 10.4.1; or
> >
> > *
> > Recall the delegation anyway and delay the operation until
> > 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.
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...
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy(a)kernel.org, trond.myklebust(a)hammerspace.com
16
days inactive
21
days old
2 comments
3 participants
participants (3)
-
Jeff Layton -
Rick Macklem -
Trond Myklebust