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
