Re: Need NFSv4.1 "WANT_DELEGATION" op ...

["Chuck Lever" <cel@kernel.org>]

On Wed, Sep 16, 2026, at 7:57 PM, Roland Mainz wrote:
> Hi!
>
> ----
>
> We're experimenting with a delegation-driven client-side
> consitency+caching model for the ms-nfs41-client Windows NFSV4.2
> client a while now.
>
> The original idea was to have two modes:
> - Mode 1: Get delegations (read delegations for accessing data
> read-only, write delegations for accessing data [a]) at OPEN time, and
> return the delegation when the file handle gets closed ([b]). The
> client only does buffering+caching if it has a delegation.
> - Model 2:  Do not request a delegation at file open/creation, instead
> translate Win32 oplocks into WANT_DELEGATION+DELEGRETURN. The client
> only does buffering+caching if it has a delegation. Server-side
> revocation of the delegation triggers an oplock break, releasing the
> oplock from the Win32 side just returns the delegation. This is
> basically how Win32 oplocks work on the SMB level.
>
> But in real life there are problems:
> - "Mode 1" only worked for small testcases. Real Windows applications
> typically change filehandle attributes or change ACLs after creating a
> file, which results in server-side delegation recall triggered by a
> NFS SETATTR, and after that we do not have a delegation. And there is
> no WANT_DELEGATION op support in Linux+FreeBSD nfsd to get a
> delegation back. Which typically means write delegations not being
> enabled and therefore no client-side buffering/caching.
> - "Mode 2" does not work because Linux+FreeBSD nfsd does not implement
> WANT_DELEGATION to implement this "on-demand delegation" model.
>
> Or short: For "mode 1" or "mode 2" to work we need the NFSV4.1
> operation "WANT_DELEGATION" to work, at least in syncronous mode (e.g.
> no CB_PUSH_DELEG support needed for now [c]).
>
> @Chuck Lever What do you think ?

Roland, thanks for raising the question here.

Playing devil's advocate for a moment. Since 2010, when RFC 5661
was published, no other client implementer has requested a server
implementation of the WANT_DELEGATION operation. That suggests:

- POSIX clients might have a hard time making use of it
- There are one or more flaws with its specification
- It might not add any benefit for real world workloads
- It might be possible to work around the lack of a
  WANT_DELEGATION operation using OPEN

I don't have any evidence of the challenges or benefits, but
these are admittedly open questions. And note:

- There is no testing infrastructure, currently
- As you found out, Wireshark does not yet implement a decoder
- Notably the Solaris NFS server also does not implement it

Even in the simpler synchronous-only mode, it's a heap of work.

I'd like to hear from POSIX client implementers. Have you
considered implementing WANT_DELEGATION, but found the
specification wanting, or is there some challenge to
introducing the plumbing in your client? I'd like to understand,
practically speaking, if WANT_DELEGATION itself is conceptually
flawed, before diving in. We'd be the first to attempt an
implementation of it.


> Why is WANT_DELEGATION an "optional" operation in NFSv4.1?

I didn't perform a deep search of pre-2010 items in the archive
of nfsv4@ietf.org, but RFC 8881 does give indications about why
WANT_DELEGATION is OPTIONAL.

- Minor-versioning rule 12: a minor version must not introduce
  REQUIRED new features except infrastructural ones.
  WANT_DELEGATION is new in 4.1 and is not infrastructural, so
  it cannot be REQUIRED.

- Feature-to-operation mapping: "For the NFSv4.1 features that
  are OPTIONAL, the operations that support those features are
  OPTIONAL, and the server would return NFS4ERR_NOTSUPP."

Underneath that is the older NFSv4 principle that delegations
are always at the server's discretion. Section 10.4 says "Making
a delegation is up to the server, and clients should not assume
that any particular OPEN either will or will not result in an
OPEN delegation". Section 10.4.7 restates it for this operation:
"servers MAY provide delegations separate from open, via the
OPTIONAL WANT_DELEGATION operation". A server that never grants
delegations has nothing to implement here, so mandating the
operation would be pointless.

The RFC treats the absence of WANT_DELEGATION as a normal case
with a fallback. Section 10.2.1 notes that "since the server is
not required to support this operation," a client reclaiming a
delegation with no associated open can instead use a dummy OPEN
with CLAIM_PREVIOUS and then CLOSE it (rfc8881.txt:9596).

So the protocol was deliberately designed so that everything
WANT_DELEGATION does can be approximated with OPEN, which is
why it sits on the OPTIONAL side of the line rather than being
treated as infrastructure like sessions and RECLAIM_COMPLETE.

It doesn't look like an oversight to me.


-- 
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)