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

["J. Bruce Fields" <[e-mail]>]

On Wed, Oct 20, 2021 at 06:50:29PM -0700, Thomas Haynes wrote:
> 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.

Return 0 to the application in the first case, and ENOTSUP in the
second?  Is that a problem?

> 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?

Unless the client's trying to do some optimization, as in Rick's case,
it doesn't sound likely to cause a problem.

I could see how EINVAL could cause practical problems, though.  E.g. an
application probably knows how to handle NOTSUPP--it can fall back on
writing zeroes, or something.  EINVAL, though, sounds like something's
just broken, and it's not clear how to recover.

Ditto a tar application getting NOTSUPP on getxattr.

You're probably right on the letter of the spec.

But we definitely need a way to indicate these features aren't supported
on a per-filesystem basis, and it sounds like NFS4ERR_NOTSUPP is likely
to work in practice, so maybe just going with that is the least bad
option....

--b.