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

[Rick Macklem <[e-mail]>]

David Noveck wrote:
> On Fri, Nov 5, 2021, 7:19 PM Rick Macklem <[e-mail]<mailto:[e-mail]>> 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.
Well, large extended attributes may be controversial, but knowing the largest size supported
by a file system on the server would still be useful, I think. It simply allows the client to fail
a request to set an xattr that is too large for the server file system without attempting a Setxattr.
(To be honest, this is not particularily important and I would have no problem dropping it
 from the list.)

--> Large extended attributes doesn't refer to "new operations". It simply refers to doing large
      sized extended attributes via the RFC8276 operations.
      --> The only protocol change that might be desirable is allowing Setxattr to be done during
            grace, whereas not allowing Getxattr during grace (after server reboot).
I will post once I hear from the other two individuals that commented in the BVat Discord
discussion. Basically, its "since neither Linux nor FreeBSD are implementing Named Attributes",
use RFC8276 xattr operations instead.
--> So, yes, I do expect it to be controversial.
>
> > 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?
All I can say that knowing that the server file system provides monotonically increasing
directory offset cookies makes the implementation of Directory Delegations practical
in the FreeBSD client. (I am thinking of working on Directory Delegation implementation
this winter, with only monotonically increasing directory offset cookies supported.)

> 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.
I'm guessing this is directed at me. I've never done one of these drafts, but I will try and come up
with one.

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