Need NFSv4.1 "WANT_DELEGATION" op ...

Need NFSv4.1 "WANT_DELEGATION" op ...

[Roland Mainz]

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.

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

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

[Lionel Cons]

On Thu, 17 Sept 2026 at 02:08, Roland Mainz <roland.mainz@nrubsig.org> 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.

History question:
Why is WANT_DELEGATION an "optional" operation in NFSv4.1?
Server can always recall a NFS delegation, but a way to get it back is
only via an "optional" NFS op?

It looks like a mistake/oversight that WANT_DELEGATION was never made
"mandatory" like the other delegation operations.

Lionel

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

[Jeff Layton]

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>

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

[Chuck Lever]

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)

Re: [Ms-nfs41-client-devel] Need NFSv4.1 "WANT_DELEGATION" op ...

[Lionel Cons]

On Thu, 17 Sept 2026 at 15:50, Chuck Lever via Ms-nfs41-client-devel
<ms-nfs41-client-devel@lists.sourceforge.net> wrote:
>
>
>
> 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.

Steve French (Linux ksmb) pointed out that problem (and it is one)
many years ago: "... The NFS client and server implementations are all
patterned after SUN's awful NFSv1 implementation, and never evolved.
Windows did evolve by introducing oplocks with Windows NT3.1, got the
superior oplock based caching model with Windows 7, and put that into
SMB. ... The UNIX (and by extension Linux) model did not evolve beyond
NFSv1. ..."
Not my words - I am not trying to insult or start a riot in a Linux
list, just quoting. Steve citing "NFSv1" (not v2) was likely some
intentional locking/exaggeration.

But Steve is right: NFSv4 was intentionally designed not only with
POSIX clients in mind, but also to cover IBM's mainframe needs, IBM
DFS-like caching needs, Windows NT needs, VMS network filesystem
needs, and so on.
If you go beyond the Linux point-of-view you see that other operating
systems do it a bit differently. CITI had the ambition to explore a
delegation-based caching model, but never got to that when the funding
ran out.

> That suggests:
>
> - POSIX clients might have a hard time making use of it

This is an issue with how the Linux and UNIX NFS clients work under
the hood. They are designed for FATTR4_CHANGE based caching model, and
delegation are handled like some minor unimportant trailing optional
detail. Otherwise people would've already stumbled over the issues
that delegations get recalled when setting file attributes. Which is a
problem for real world usage on shared files opened for a long time,
but only for big things like compiling clang on a NFS share. The
average userland script kiddle would not even notice.

Lionel

Re: [Ms-nfs41-client-devel] Need NFSv4.1 "WANT_DELEGATION" op ...

[Lionel Cons]

On Thu, 17 Sept 2026 at 15:50, Chuck Lever via Ms-nfs41-client-devel
<ms-nfs41-client-devel@lists.sourceforge.net> wrote:
> 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).

I had to refer to a colleague for this one. The answer:
"... CLAIM_PREVIOUS is only valid during reclaim. Outside the server's
grace/recovery period, a compliant server must reject it. ..."

I think that is why WANT_DELEGATION was added to RFC 5661

Lionel

Re: [Ms-nfs41-client-devel] Need NFSv4.1 "WANT_DELEGATION" op ...

[Rick Macklem]

On Sat, Sep 19, 2026 at 4:43 AM Lionel Cons <lionelcons1972@gmail.com> wrote:
>
> CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you are unsure, forward the message to ITHelp@uoguelph.ca for review.
>
>
> On Thu, 17 Sept 2026 at 15:50, Chuck Lever via Ms-nfs41-client-devel
> <ms-nfs41-client-devel@lists.sourceforge.net> wrote:
> > 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).
>
> I had to refer to a colleague for this one. The answer:
> "... CLAIM_PREVIOUS is only valid during reclaim. Outside the server's
> grace/recovery period, a compliant server must reject it. ..."
Yes, the above does refer to reclaim during grace.

However, I do not see why a client cannot do an OPEN/CLAIM_FH
for a file where the client already has an OPEN for the same file
for the same owner.
This is normally done to upgrade from OPEN4_SHARE_ACCESS_READ
to OPEN4_SHARE_ACCESS_BOTH, but all the RFC says is that the
access bits are or'd together. (It does not say that the new bits must be
different than what is already done for the OPEN.)
At least for the FreeBSD server, it appears to allow this for "same access bits"
and will issue the delegation based on the OPEN4_SHARE_ACCESS_WANT_xxx_DELEG
bit, using the same rules as an OPEN where file is not yet OPEN'd and the same
rules that a WANT_DELEGATION would apply if it were implemented.

I'd suggest that you explore using the above, since you are only doing
it for an "experimental caching model" at this time.

rick

>
> I think that is why WANT_DELEGATION was added to RFC 5661
>
> Lionel
>

Re: [Ms-nfs41-client-devel] Need NFSv4.1 "WANT_DELEGATION" op ...

[Lionel Cons]

On Sat, 19 Sept 2026 at 21:22, Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Sat, Sep 19, 2026 at 4:43 AM Lionel Cons <lionelcons1972@gmail.com> wrote:
> >
> > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you are unsure, forward the message to ITHelp@uoguelph.ca for review.
> >
> >
> > On Thu, 17 Sept 2026 at 15:50, Chuck Lever via Ms-nfs41-client-devel
> > <ms-nfs41-client-devel@lists.sourceforge.net> wrote:
> > > 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).
> >
> > I had to refer to a colleague for this one. The answer:
> > "... CLAIM_PREVIOUS is only valid during reclaim. Outside the server's
> > grace/recovery period, a compliant server must reject it. ..."
> Yes, the above does refer to reclaim during grace.
>
> However, I do not see why a client cannot do an OPEN/CLAIM_FH
> for a file where the client already has an OPEN for the same file
> for the same owner.
> This is normally done to upgrade from OPEN4_SHARE_ACCESS_READ
> to OPEN4_SHARE_ACCESS_BOTH, but all the RFC says is that the
> access bits are or'd together. (It does not say that the new bits must be
> different than what is already done for the OPEN.)
> At least for the FreeBSD server, it appears to allow this for "same access bits"
> and will issue the delegation based on the OPEN4_SHARE_ACCESS_WANT_xxx_DELEG
> bit, using the same rules as an OPEN where file is not yet OPEN'd and the same
> rules that a WANT_DELEGATION would apply if it were implemented.
>
> I'd suggest that you explore using the above,

At least for MS nfsd and OTAP nfsd this does not work outside the
recovery period.

> since you are only doing
> it for an "experimental caching model" at this time.

Well, it's already in the tree, and slated to be the only caching model.

Lionel

Re: [Ms-nfs41-client-devel] Need NFSv4.1 "WANT_DELEGATION" op ...

[Rick Macklem]

On Sun, Sep 20, 2026 at 10:32 AM Lionel Cons <lionelcons1972@gmail.com> wrote:
>
> On Sat, 19 Sept 2026 at 21:22, Rick Macklem <rick.macklem@gmail.com> wrote:
> >
> > On Sat, Sep 19, 2026 at 4:43 AM Lionel Cons <lionelcons1972@gmail.com> wrote:
> > >
> > > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you are unsure, forward the message to ITHelp@uoguelph.ca for review.
> > >
> > >
> > > On Thu, 17 Sept 2026 at 15:50, Chuck Lever via Ms-nfs41-client-devel
> > > <ms-nfs41-client-devel@lists.sourceforge.net> wrote:
> > > > 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).
> > >
> > > I had to refer to a colleague for this one. The answer:
> > > "... CLAIM_PREVIOUS is only valid during reclaim. Outside the server's
> > > grace/recovery period, a compliant server must reject it. ..."
> > Yes, the above does refer to reclaim during grace.
> >
> > However, I do not see why a client cannot do an OPEN/CLAIM_FH
> > for a file where the client already has an OPEN for the same file
> > for the same owner.
> > This is normally done to upgrade from OPEN4_SHARE_ACCESS_READ
> > to OPEN4_SHARE_ACCESS_BOTH, but all the RFC says is that the
> > access bits are or'd together. (It does not say that the new bits must be
> > different than what is already done for the OPEN.)
> > At least for the FreeBSD server, it appears to allow this for "same access bits"
> > and will issue the delegation based on the OPEN4_SHARE_ACCESS_WANT_xxx_DELEG
> > bit, using the same rules as an OPEN where file is not yet OPEN'd and the same
> > rules that a WANT_DELEGATION would apply if it were implemented.
> >
> > I'd suggest that you explore using the above,
>
> At least for MS nfsd and OTAP nfsd this does not work outside the
> recovery period.
Nope. I said use CLAIM_FH (not CLAIM_PREVIOUS). An OPEN with CLAIM_FH
for a file that is already open'd is a normal "upgrade", so it has to
be supported by
servers outside of grace (and not allowed during grace).

RFC8881 says..
   When an OPEN is done and the specified open-owner already has the
   resulting filehandle open, the result is to "OR" together the new
   share and deny status together with the existing status.  In this
   case, only a single CLOSE need be done, even though multiple OPENs
   were completed.  When such an OPEN is done, checking of share
   reservations for the new OPEN proceeds normally, with no exception
   for the existing OPEN held by the same open-owner.  In this case, the
   stateid returned as an "other" field that matches that of the
   previous open while the "seqid" field is incremented to reflect the
   change status due to the new open.
Note that it does not say anything specific w.r.t. the
OPEN4_SHARE_ACCESS_WANT_READ/WRITE_DELEG bits,
so I cannot predict what other NFSv4.1 servers will do w.r.t. those
for this type of OPEN.

>
> > since you are only doing
> > it for an "experimental caching model" at this time.
>
> Well, it's already in the tree, and slated to be the only caching model.
Ok. But if it doesn't work well without WANT_DELEGATION and servers
aren't supporting WANT_DELEGATION, that doesn't sound like a great
plan to me?

rick

>
> Lionel