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

[Jeff Layton <jlayton@kernel.org>]

On Thu, 2026-09-17 at 01:57 +0200, 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 ?
> 
> [a] Win32 also supports opening a file for attributes only, which
> means no delegation gets requested
> [b] Note that WIndows supports close-delayed files, which means that
> calling |CloseHandle()| will flush outstanding dirty data, but keeps
> the file "active" in the driver for re-use for some time (except on
> delete/rename/etc.). For the NFS driver this means that locks are
> returned, but the delegation+buffering stays untouched.
> [c] Technically requesting WANT_DELEGATION async via CB_PUSH_DELEG
> would be a welcome optimisation, because it could help dealing with
> files with high contention between machines.
> 


I think we could probably do a trivial WANT_DELEGATION implementation
(with no callbacks) in knfsd without too much trouble. We have the
infrastructure to handle granting delegations at OPEN, so we could just
factor that out for WANT_DELEGATION.

Registering a callback to acquire and grant the delegation however is
quite a bit more tricky to handle, and opens a lot of questions about
how to handle competing WANT_DELEGATIONs from different clients.

-- 
Jeff Layton <jlayton@kernel.org>