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

> On Oct 20, 2021, at 10:02 PM, David Noveck <davenoveck@gmail.com> wrote:
> 
> Section 15.1.1.5 is a problem, although, as Bruce points out, it may not be problem returning NOTSUPP in practice.
> 

Perhaps the solution is to add a per-file system attribute to state whether or not it supports the optional feature.

> I'm thinking about updating this definition in rfc5661bis-03 together with dealing with a bunch of the remaining erratta reports and a few updates to the security discussion to respond to the changes in security-03.
> I would submit this right after security-03, even though the big split up of the bis is still a ways in the future.
> 
>  I think we can spend a few minutes discussing this at the meeting next week
> 
> 
> 
> On Wed, Oct 20, 2021, 10:18 PM J. Bruce Fields <bfields@fieldses.org <mailto:bfields@fieldses.org>> wrote:
> 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.
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org <mailto:nfsv4@ietf.org>
> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>