BUG: Linux 6.12 nfsd does not support FATTR4_WORD2_CHANGE_ATTR_TYPE in NFSv4.2 mode!!

BUG: Linux 6.12 nfsd does not support FATTR4_WORD2_CHANGE_ATTR_TYPE in NFSv4.2 mode!!

[Takeshi Nishimura]

Dear list,

We tried to use FATTR4_WORD2_CHANGE_ATTR_TYPE with Linux 6.12 nfsd,
but the server does not set that attribute, while it is mandatory for
NFSv4.2.
Could this please be fixed?
-- 
Internationalization&localization dev / 大阪大学
Takeshi Nishimura <takeshi.nishimura.linux@gmail.com>

Re: BUG: Linux 6.12 nfsd does not support FATTR4_WORD2_CHANGE_ATTR_TYPE in NFSv4.2 mode!!

[Rick Macklem]

On Sat, Jan 11, 2025 at 12:08 PM Takeshi Nishimura
<takeshi.nishimura.linux@gmail.com> wrote:
>
> Dear list,
>
> We tried to use FATTR4_WORD2_CHANGE_ATTR_TYPE with Linux 6.12 nfsd,
> but the server does not set that attribute, while it is mandatory for
> NFSv4.2.
My understand is that nothing is mandatory in NFSv4.2. Everything is considered
optional extensions. I doubt any extant 4.2 server supports all of the optional
extensions in NFSv4.2.

> Could this please be fixed?
I'll leave if/when this optional extension will be added to the Linux
knfsd to the
Linux folk.

rick

> --
> Internationalization&localization dev / 大阪大学
> Takeshi Nishimura <takeshi.nishimura.linux@gmail.com>
>

Re: BUG: Linux 6.12 nfsd does not support FATTR4_WORD2_CHANGE_ATTR_TYPE in NFSv4.2 mode!!

[Chuck Lever]

On 1/11/25 3:08 PM, Takeshi Nishimura wrote:
> Dear list,
> 
> We tried to use FATTR4_WORD2_CHANGE_ATTR_TYPE with Linux 6.12 nfsd,

Help us understand what "We tried to use" means. Which NFS client
implementation, and how does it intend to use this information?
Please provide more detail than the general discussion in RFC 7862
Section 10, please.

For instance, RFC 7862 Section 12.2.3, final paragraph says:

    Finally, if the server does not support change_attr_type or if
    NFS4_CHANGE_TYPE_IS_UNDEFINED is set, then the server SHOULD make an
    effort to implement the change attribute in terms of the
    time_metadata attribute.

NFSD could implement change_attr_type4 and simply return 
TYPE_IS_UNDEFINED.... that would be 100% spec-compliant. But how is
that helpful? I'd like to hear more detail about what benefit your
client expects and why it can't work without the change_attr_type
information.


> but the server does not set that attribute, while it is mandatory for
> NFSv4.2.

To be clear, RFC 7862 Section 10 says that this attribute is not
mandatory:

             change_attr_type is defined as a new recommended attribute
    (see Section 12.2.3) and is a per-file system attribute.

The term "recommended" here has the particular meaning "not required".

In addition, Section 1.2 states:

    NFSv4.2 is a superset of NFSv4.1, with all of the new features being
    optional.

This means NFSv4.2 clients have to be prepared for NFSv4.2 servers to
not implement that attribute. If your client is choking simply because
the server reports change_attr_type4 is not implemented, that's a client
bug.


> Could this please be fixed?

This is technically not an NFSD bug. AFAICT NFSD complies with spec in
this regard.

But it is fair game as a Request for Enhancement. If you can give some
more detail about how you think this attribute should work, that would
help!

(Jeff, this seems like follow-on to the multi-grain work. Can you have a
look?)


-- 
Chuck Lever

Re: BUG: Linux 6.12 nfsd does not support FATTR4_WORD2_CHANGE_ATTR_TYPE in NFSv4.2 mode!!

[Takeshi Nishimura]

On Sat, Jan 11, 2025 at 10:17 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Sat, Jan 11, 2025 at 12:08 PM Takeshi Nishimura
> <takeshi.nishimura.linux@gmail.com> wrote:
> >
> > Dear list,
> >
> > We tried to use FATTR4_WORD2_CHANGE_ATTR_TYPE with Linux 6.12 nfsd,
> > but the server does not set that attribute, while it is mandatory for
> > NFSv4.2.
> My understand is that nothing is mandatory in NFSv4.2. Everything is considered
> optional extensions. I doubt any extant 4.2 server supports all of the optional
> extensions in NFSv4.2.

That can't be true, or would be a bug in the NFSv4.2 spec then.
"Everything optional" means feature support gets fragmented, and
interoperability will cease to exist.
-- 
Internationalization&localization dev / 大阪大学
Takeshi Nishimura <takeshi.nishimura.linux@gmail.com>

Re: BUG: Linux 6.12 nfsd does not support FATTR4_WORD2_CHANGE_ATTR_TYPE in NFSv4.2 mode!!

[Jeff Layton]

On Sat, 2025-01-11 at 13:17 -0800, Rick Macklem wrote:
> On Sat, Jan 11, 2025 at 12:08 PM Takeshi Nishimura
> <takeshi.nishimura.linux@gmail.com> wrote:
> > 
> > Dear list,
> > 
> > We tried to use FATTR4_WORD2_CHANGE_ATTR_TYPE with Linux 6.12 nfsd,
> > but the server does not set that attribute, while it is mandatory for
> > NFSv4.2.
> My understand is that nothing is mandatory in NFSv4.2. Everything is considered
> optional extensions. I doubt any extant 4.2 server supports all of the optional
> extensions in NFSv4.2.
> 

Correct. This attr is completely optional.

> > Could this please be fixed?
> I'll leave if/when this optional extension will be added to the Linux
> knfsd to the
> Linux folk.
> 

See:

    1631087ba872 Revert "nfsd4: support change_attr_type attribute"

Upshot: we had this at one point, but ripped it out because it was't
terribly useful and could be problematic if the clock jumps backward.
We could add it back in again, but we'd need to understand how to
address the problems that Bruce points out.

-- 
Jeff Layton <jlayton@kernel.org>

Re: BUG: Linux 6.12 nfsd does not support FATTR4_WORD2_CHANGE_ATTR_TYPE in NFSv4.2 mode!!

[Jeff Layton]

On Mon, 2025-01-13 at 05:06 +0100, Takeshi Nishimura wrote:
> On Sat, Jan 11, 2025 at 10:17 PM Rick Macklem <rick.macklem@gmail.com> wrote:
> > 
> > On Sat, Jan 11, 2025 at 12:08 PM Takeshi Nishimura
> > <takeshi.nishimura.linux@gmail.com> wrote:
> > > 
> > > Dear list,
> > > 
> > > We tried to use FATTR4_WORD2_CHANGE_ATTR_TYPE with Linux 6.12 nfsd,
> > > but the server does not set that attribute, while it is mandatory for
> > > NFSv4.2.
> > My understand is that nothing is mandatory in NFSv4.2. Everything is considered
> > optional extensions. I doubt any extant 4.2 server supports all of the optional
> > extensions in NFSv4.2.
> 
> That can't be true, or would be a bug in the NFSv4.2 spec then.
> "Everything optional" means feature support gets fragmented, and
> interoperability will cease to exist.

Not true. NFSv4.2 is composed entirely of optional features. It's
totally legitimate for an endpoint to just report that it supports
minorversion 2, and do nothing else, and it's now compliant.

For this attr, it's even written in the spec!

    12.1.  New RECOMMENDED Attributes - List and Definition References

That said, I'd be happy to help review patches that add this, but I'd
take a look 1631087ba8727db03c0ab2815dc06dc25d962b80 where we reverted
this before.

If the server experiences a clock jump backward, then you could end up
with a duplicate change attribute for a different file state. There is
some question about whether that means that we can't claim that the
attr is MONOTONIC.
-- 
Jeff Layton <jlayton@kernel.org>

Re: BUG: Linux 6.12 nfsd does not support FATTR4_WORD2_CHANGE_ATTR_TYPE in NFSv4.2 mode!!

[Chuck Lever]

On 1/12/25 11:06 PM, Takeshi Nishimura wrote:
> On Sat, Jan 11, 2025 at 10:17 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>>
>> On Sat, Jan 11, 2025 at 12:08 PM Takeshi Nishimura
>> <takeshi.nishimura.linux@gmail.com> wrote:
>>>
>>> Dear list,
>>>
>>> We tried to use FATTR4_WORD2_CHANGE_ATTR_TYPE with Linux 6.12 nfsd,
>>> but the server does not set that attribute, while it is mandatory for
>>> NFSv4.2.
>> My understand is that nothing is mandatory in NFSv4.2. Everything is considered
>> optional extensions. I doubt any extant 4.2 server supports all of the optional
>> extensions in NFSv4.2.
> 
> That can't be true, or would be a bug in the NFSv4.2 spec then.
> "Everything optional" means feature support gets fragmented, and
> interoperability will cease to exist.

Hello -

Interoperability in this case means that the client is able to determine
whether the server implements a new feature, and then not use it if the
server hasn't implemented it.

There are protocol mechanisms in place to ensure that clients can
recognize that the server doesn't support any feature introduced by
NFSv4.2, so it is entirely safe to make them all optional.

As RFC 7862 points out, when a server lacks support for
FATTR4_CHANGE_ATTR_TYPE, the client is supposed to behave as if the
server returned TYPE_IS_UNDEFINED.


-- 
Chuck Lever