From: Jeff Layton <jlayton@kernel.org>
To: Olga Kornievskaia <aglo@umich.edu>
Cc: linux-nfs@vger.kernel.org,
Trond Myklebust <trondmy@hammerspace.com>,
Anna Schumaker <anna@kernel.org>
Subject: Re: xfstest failures depending on delegated_attributes on/off
Date: Thu, 26 Feb 2026 10:05:39 -0500 [thread overview]
Message-ID: <ce051694987719b387563ae2a91ab0f3a32a1e66.camel@kernel.org> (raw)
In-Reply-To: <CAN-5tyH0t39mysTaRE=5Do6HOABQ8YdHjs2kxhadXcWcVhC8ag@mail.gmail.com>
On Wed, 2026-02-25 at 14:57 -0500, Olga Kornievskaia wrote:
> Hi Jeff,
>
> The list of failures I see, on the kernel build from the following
> kernel tree (Chuck's nfsd-testing branch) (on vers=4.2, sec=sys):
> commit 17081b01a9b6f0e7a31342cef03102d91733f1c2 (HEAD ->
> 02252026-nfsd-testing, origin/nfsd-testing)
>
> generic/221, generic/407, generic/728 (fail if delegated attributes
> are turned on and succeed otherwise). Do you see any of them?
>
> I'm currently investigating generic/751 but I've yet to determine if
> delegated attributes help or hurt there (but toggle makes things run
> (and fail) differently). After that I was planning to take a look at
> the others.
(cc'ing Olga's bug report to a wider audience)
Sorry, meant to follow up on the others:
generic/407 passes for me with delegated timestamps. Can you look into
that one a bit more? generic/751 fails for me though. I suspect this is
a client-side bug too:
The REMOVEXATTR compound doesn't contain a GETATTR, so the client
doesn't update its timestamps after issuing one. The SETXATTR compound
does contain one, so one probably just needs to be added:
No. Time Source Destination Protocol Length Info
35 09:45:20.287193 192.168.122.158 192.168.122.129 NFS 362 V4 Call (Reply In 36) OPEN DH: 0x60a9c780/testfile
36 09:45:20.292964 192.168.122.129 192.168.122.158 NFS 506 V4 Reply (Call In 35) OPEN StateID: 0xafa9
38 09:45:22.387717 192.168.122.158 192.168.122.129 NFS 290 V4 Call (Reply In 39) SETXATTR
39 09:45:22.390218 192.168.122.129 192.168.122.158 NFS 250 V4 Reply (Call In 38) SETXATTR
41 09:45:24.518285 192.168.122.158 192.168.122.129 NFS 262 V4 Call (Reply In 42) REMOVEXATTR
42 09:45:24.520337 192.168.122.129 192.168.122.158 NFS 186 V4 Reply (Call In 41) REMOVEXATTR
44 09:45:44.550896 192.168.122.158 192.168.122.129 NFS 194 V4 Call (Reply In 45) SEQUENCE
45 09:45:44.551913 192.168.122.129 192.168.122.158 NFS 150 V4 Reply (Call In 44) SEQUENCE
46 09:45:44.552221 192.168.122.158 192.168.122.129 NFS 346 V4 Call (Reply In 51) SETATTR FH: 0x559aaf9c | DELEGRETURN StateID: 0x33d9
48 09:45:44.553823 192.168.122.158 192.168.122.129 NFS 346 V4 Call (Reply In 50) SETATTR FH: 0xc275dd69 | DELEGRETURN StateID: 0x674c
It looks like without delegated timestamps, the client does an on-the-wire GETATTR after the REMOVEXATTR:
No. Time Source Destination Protocol Length Info
197 09:58:19.129157 192.168.122.158 192.168.122.129 NFS 362 V4 Call (Reply In 198) OPEN DH: 0x60a9c780/testfile
198 09:58:19.133943 192.168.122.129 192.168.122.158 NFS 506 V4 Reply (Call In 197) OPEN StateID: 0xafa9
199 09:58:19.135941 192.168.122.158 192.168.122.129 NFS 306 V4 Call (Reply In 200) SETATTR FH: 0xb007cc80
200 09:58:19.138457 192.168.122.129 192.168.122.158 NFS 294 V4 Reply (Call In 199) SETATTR
202 09:58:21.233187 192.168.122.158 192.168.122.129 NFS 290 V4 Call (Reply In 203) SETXATTR
203 09:58:21.235414 192.168.122.129 192.168.122.158 NFS 250 V4 Reply (Call In 202) SETXATTR
205 09:58:23.367791 192.168.122.158 192.168.122.129 NFS 262 V4 Call (Reply In 206) REMOVEXATTR
206 09:58:23.369903 192.168.122.129 192.168.122.158 NFS 186 V4 Reply (Call In 205) REMOVEXATTR
208 09:58:23.406309 192.168.122.158 192.168.122.129 NFS 262 V4 Call (Reply In 209) GETATTR FH: 0xb007cc80
209 09:58:23.407822 192.168.122.129 192.168.122.158 NFS 266 V4 Reply (Call In 208) GETATTR
211 09:58:42.791073 192.168.122.158 192.168.122.129 NFS 194 V4 Call (Reply In 212) SEQUENCE
212 09:58:42.792068 192.168.122.129 192.168.122.158 NFS 150 V4 Reply (Call In 211) SEQUENCE
213 09:58:42.792464 192.168.122.158 192.168.122.129 NFS 282 V4 Call (Reply In 215) DELEGRETURN StateID: 0x2cd6
215 09:58:42.794509 192.168.122.129 192.168.122.158 NFS 230 V4 Reply (Call In 213) DELEGRETURN
217 09:59:03.270925 192.168.122.158 192.168.122.129 NFS 194 V4 Call (Reply In 218) SEQUENCE
218 09:59:03.272006 192.168.122.129 192.168.122.158 NFS 150 V4 Reply (Call In 217) SEQUENCE
220 09:59:03.273179 192.168.122.158 192.168.122.129 NFS 282 V4 Call (Reply In 221) DELEGRETURN StateID: 0xbbe2
221 09:59:03.275087 192.168.122.129 192.168.122.158 NFS 230 V4 Reply (Call In 220) DELEGRETURN
--
Jeff Layton <jlayton@kernel.org>
prev parent reply other threads:[~2026-02-26 15:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAN-5tyH0t39mysTaRE=5Do6HOABQ8YdHjs2kxhadXcWcVhC8ag@mail.gmail.com>
2026-02-26 14:36 ` xfstest failures depending on delegated_attributes on/off Jeff Layton
2026-02-26 15:05 ` Jeff Layton [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=ce051694987719b387563ae2a91ab0f3a32a1e66.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=aglo@umich.edu \
--cc=anna@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@hammerspace.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