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

[David Noveck <[e-mail]>]

Although this issue has been satisfactorily resolved via the discussion in
the list,  I think it is reasonable to update the specs to clarify the
meaning of "conflicting" and the proper relationship of READ opens and
WRITE delegations.  I expect to address this in rfc8881bis-10









On Friday, October 31, 2025, Jeff Layton <[e-mail]> 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 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> --
> Jeff Layton <[e-mail]>
>
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>