Re: [nfsv4] Can NFSv4.2 operations be optional on a per server file system basis?

[Rick Macklem <[e-mail]>]

Well, what do others think of this?

Thomas Haynes wrote:
> The answer is “no”.
Well Tom, when I first red RFC7862 I assumed that the "optional features" were
"per server", but when I look in the RFC I cannot see that stated.
In Sec. 1.2:
   NFSv4.2 is a superset of NFSv4.1, with all of the new features being
   optional.  As such, NFSv4.2 maintains the same compatibility that
   NFSv4.1 had with NFSv4.0.  Any interactions of a new feature with
   NFSv4.1 semantics is described in the relevant text.

It clearly states that all new features are optional. It does not state if the
option is "per server" or  "per server file system" (or "per server file" for that
matter).

Then in Sec. 1.3:
   A major goal of the enhancements provided in NFSv4.2 is to take
   common local file system features that have not been available
   through earlier versions of NFS and to offer them remotely.  These
   features might
This kinda hints that the new features are based on local file systems
in the server, so supporting the new feature "per server file system"
doesn't seem too much of a stretch?

I could not see any statement that optional features were "per server"
in the RFC (but I might have just missed it?).

Then J. Bruce Fields wrote:
> For what it's worth, I looked at the Linux knfsd code, and it looks like
> it will in fact return NFS4ERR_NOTSUPP in this case.
>
> That's probably not the only case.  E.g. (again from just looking at the
> code) I suspect that's what we do you request an xattr from a filesystem
> that lacks xattr support (even though GETXATTR is supported and might
> succeed given a filehandle on another export).
>
> Without testing right now, I *think* the Linux client just passes that
> back to the application (probably as EOPNOTSUPP).  It doesn't give up on
> ever using FALLOCATE against that server again.
So, it appears that the Linux knfsd server is shipping with optional features
on a "per server file system" basis and that the Linux NFSv4.2 client handles
that.

The FreeBSD NFSv4.2 client is slightly broken, in that it has an "optimization"
where, if it sees a NFS4ERR_NOTSUPP reply, it marks the operation not supported
and does not attempt it again. This optimization could easily be removed for the
next release and appears to be broken w.r.t. extant Linux knfsd servers, so I should
remove it anyhow.

So, could we just clarify that NFSv4.2 optional features are "per server file system"?

rick

--b.