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

On Fri, Nov 5, 2021, 7:19 PM Rick Macklem <rmacklem@uoguelph.ca> wrote:

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

We could add these as optional extensions to v4.2.  Adding a single
attribute is probably not worth it, but, since I expect these to be
non-controversial doing them as a single document would not be a lot of
work.

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

Agree.

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

Good idea.  The natural tendency is to assume that this value matches that
of your local file system so it is good to provide the true value.

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

I'd like to see that post.   If that post makes this attribute
controversial, you have the option of splitting it out and dealing with it
in a separate document.

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

Do you really mean "could" or is "would" more appropriate?

>
I'm already planning on new descriptions of directory delegation and
notification for rfc5661bis.  As I think about that, I will come up with my
own opinion on the could/would question.

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

That's a longstanding need.  It would be good to address it.

> What do others think?
>

Once an I-D is out, you may get requests for additions.  In general that is
OK, but you have to be prepared to say "no" to ideas which might interfere
with quick adoption by generating controversy.

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