From: Chuck Lever <chuck.lever@oracle.com>
To: Takeshi Nishimura <takeshi.nishimura.linux@gmail.com>,
Jeff Layton <jlayton@kernel.org>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: BUG: Linux 6.12 nfsd does not support FATTR4_WORD2_CHANGE_ATTR_TYPE in NFSv4.2 mode!!
Date: Sun, 12 Jan 2025 13:30:36 -0500 [thread overview]
Message-ID: <2f38fb42-bc02-41c5-968f-b3f6f9ffcdcf@oracle.com> (raw)
In-Reply-To: <CALWcw=EPJk3XFNfXG95v4A3Dq7=spqh5aLYru05r9Lm-eVep6w@mail.gmail.com>
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
prev parent reply other threads:[~2025-01-12 18:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-11 20:08 BUG: Linux 6.12 nfsd does not support FATTR4_WORD2_CHANGE_ATTR_TYPE in NFSv4.2 mode!! Takeshi Nishimura
2025-01-11 21:17 ` Rick Macklem
2025-01-13 4:06 ` Takeshi Nishimura
2025-01-13 12:34 ` Jeff Layton
2025-01-13 13:54 ` Chuck Lever
2025-01-13 12:27 ` Jeff Layton
2025-01-12 18:30 ` Chuck Lever [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2f38fb42-bc02-41c5-968f-b3f6f9ffcdcf@oracle.com \
--to=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=takeshi.nishimura.linux@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox