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

> On Oct 20, 2021, at 5:10 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote:
> 
> 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?).

Honestly I went with what I *thought* I intended. The best supporting evidence is here:

15.1.1.5.  NFS4ERR_NOTSUPP (Error Code 10004)

   Operation not supported, either because the operation is an OPTIONAL
   one and is not supported by this server or because the operation MUST
   NOT be implemented in the current minor version.

Which implies that the if OPTIONAL the operation is either entirely supported by the server or not.

What is a client supposed to do if it tries ALLOCATE and the server accepts it -- it tries again and the server replies NFS4ERR_NOTSUPP.  Is the support based on time of day? Did something change on the server?

You and I may know it is by filesystem, by how is that exposed to the client?

> 
> 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.
> 
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4