Subject: [nfsv4] How do I indicate non-support of _WANT_ flags?

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 10 Oct 2011 15:25:13 -0400

The DESCRIPTION section for OPEN says on page 451 says:

	"If the server supports the new _WANT_ flags and the client
	sends one or more of the new flags, then in the event the server
	does not return a delegation, it MUST..."

But it doesn't explain what to do if the server does *not* support the
new _WANT_ flags.

Any ideas?

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 10 Oct 2011 15:42:33 -0400

> But it doesn't explain what to do if the server does *not* support the

The choice would be between NFS4ERR_SHARE_DENIED and NFS4ERR_INVAL.
Given that the former is supposed to be a transient error, I'd go with
NFS4ERR_INVAL in order to prevent the client from waiting and trying
again.

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 10 Oct 2011 15:49:19 -0400

> NFS4ERR_INVAL in order to prevent the client from waiting and trying

Damn! Another wart in RFC3530bis, Tom!

The pseudocode in Section 9.9 (former section 8.9 in RFC3530) says you
should return NFS4ERR_DENIED instead of NFS4ERR_SHARE_DENIED. That
conflicts both with RFC5661 and with Section 15.18.5 in RFC3530bis.

NetApp

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 10 Oct 2011 16:36:53 -0400

> NFS4ERR_INVAL in order to prevent the client from waiting and trying

Actually, I think I'm being dumb, the obvious answer's much simpler: the
server should just do nothing if it doesn't support the WANT flags.

In the case a delegation isn't granted, the client will find out about
the non-support by the lack of an OPEN_DELEGATIN_NONE_EXT return.  In
other cases maybe it will be left not knowing whether the WANT flag did
anything or not.   But it doesn't look to me like that causes any
problems.

--b.