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

From: Rick Macklem <[email-masked]>
Date: Fri, 5 Nov 2021 23:19:29 +0000

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

---

From: David Noveck <[email-masked]>
Date: Wed, 10 Nov 2021 06:13:06 -0500

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

>     error for "per file system support" is agreed upon.

Agree.

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

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

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

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

---

From: Rick Macklem <[email-masked]>
Date: Wed, 10 Nov 2021 16:22:56 +0000

David Noveck wrote:
> On Fri, Nov 5, 2021, 7:19 PM Rick Macklem <[email-masked]<mailto:[email-masked]>> wrote:
> > Thomas Haynes wrote:
> 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.
>
>
> 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.
>
> 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.
> 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.
>
>
> 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

On Wed, Oct 20, 2021, 10:18 PM J. Bruce Fields <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:

--b.

_______________________________________________
nfsv4 mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
https://www.ietf.org/mailman/listinfo/nfsv4