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

[Rick Macklem <[e-mail]>]

Thomas Haynes wrote:
>David Noveck 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.
That would be a lot more bother to implement in FreeBSD, since the nfsd only knows if an operation
(VOP_xxx() call) is supported by calling it, and there is no convenient file VOP_ALLOCATE() could be
called using it to test for support.
--> Yes, some new FreeBSD specific pathconf values could be added to do this, but it would be a lot more
       work than just translating the error return for not supported (typically EINVAL in FreeBSD's case) to
       NFS4ERR_xxx.

It also doesn't deal with the extant Linux knfsd servers that are already shipping to users.

rick




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