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

[David Noveck <[e-mail]>]

Section 15.1.1.5 is a problem, although, as Bruce points out, it may not be
problem returning NOTSUPP in practice.

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>