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

[Rick Macklem <[e-mail]>]

Thomas Haynes wrote:
> On Oct 20, 2021, at 10:02 PM, 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.
Although I still feel that an error reply is the more "natural fit" for this
issue, I am not against a new attribute.
There are also several other new attributes I think might be useful.
Here's my current list:
(All would be read-only, per file system attributes)

counted word array (like supported_attrs) - Optional operations
    supported by file system (a bit for each operation, based on
    operation number). Still could be useful, even if a server reply
    error for "per file system support" is agreed upon.

uint64_t - minimum unallocated hole size - useful for Seek and
    maybe Allocate, Deallocate. (FreeBSD has a pathconf variable
    called _PC_MIN_HOLE_SIZE, where
    0 - not supported
    1 - supported, but no fixed granularity
    > 1 - smallest size of block that might not be allocated

uint64_t - largest extended attribute size
    (I am planning on a separate post w.r.t. large extended attributes.)

boolean - monotonically increasing directory offset cookie
    This could be useful for client side directory caching and
    client implementation of directory delegations.

boolean - server is doing mandatory byte range locking
    This is needed for a client to correctly do file caching when
    a server enforces mandatory byte range locking.

What do others think?

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