From: Jeff Layton <jlayton@kernel.org>
To: Trond Myklebust <trondmy@hammerspace.com>,
Anna Schumaker <anna@kernel.org>
Cc: linux-nfs@vger.kernel.org, Chuck Lever <chuck.lever@oracle.com>
Subject: client-side xfstest failures with delegated attributes
Date: Mon, 02 Mar 2026 14:04:21 -0500 [thread overview]
Message-ID: <c4dcc644fa65036f9bcae63e64b66509db85efc1.camel@kernel.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 7123 bytes --]
I sent a couple of fragmented emails last week about these problems,
but didn't get a response. Let me try again.
With v7.0, we're now enabling delegated timestamps by default in knfsd.
There is a runtime switch in debugfs for disabling them. Olga was doing
some testing with this and hit a couple of test failures in xfstests. I
took a look and I believe them to be client-side bugs. My analysis of
both problems is below.
generic/221:
Here is the strace of the program that it's running:
9234 creat("file", 0600) = 3
9234 fstat(3, {st_dev=makedev(0, 0x38), st_ino=115480, st_mode=S_IFREG|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=1048576, st_blocks=0, st_size=0, st_atime=1000000000 /* 2001-09-08T21:46:40-0400 */, st_atime_nsec=0, st_mtime=1772114154 /* 2026-02-26T08:55:54.240765990-0500 */, st_mtime_nsec=240765990, st_ctime=1772114154 /* 2026-02-26T08:55:54.240765990-0500 */, st_ctime_nsec=240765990}) = 0
9234 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, 0x7ffff9da2e50) = 0
9234 utimensat(3, NULL, [{tv_sec=1000000000, tv_nsec=0} /* 2001-09-08T21:46:40-0400 */, UTIME_OMIT], 0) = 0
9234 fstat(3, {st_dev=makedev(0, 0x38), st_ino=115480, st_mode=S_IFREG|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=1048576, st_blocks=0, st_size=0, st_atime=1000000000 /* 2001-09-08T21:46:40-0400 */, st_atime_nsec=0, st_mtime=1772114154 /* 2026-02-26T08:55:54.240765990-0500 */, st_mtime_nsec=240765990, st_ctime=1772114154 /* 2026-02-26T08:55:54.240765990-0500 */, st_ctime_nsec=240765990}) = 0
...and then eventually it closes the file when the program exits. The
ctime should change due to the utimensat() call.
I attached the capture. The network trace of the relevant part looks
like this:
No. Time Source Destination Protocol Length Info
15 08:55:54.238880 192.168.122.158 192.168.122.129 NFS 334 V4 Call (Reply In 16) OPEN DH: 0xf31a816b/
16 08:55:54.242641 192.168.122.129 192.168.122.158 NFS 446 V4 Reply (Call In 15) OPEN StateID: 0xafa9
17 08:56:08.806830 192.168.122.158 192.168.122.129 NFS 194 V4 Call (Reply In 18) SEQUENCE
18 08:56:08.808234 192.168.122.129 192.168.122.158 NFS 150 V4 Reply (Call In 17) SEQUENCE
19 08:56:29.287004 192.168.122.158 192.168.122.129 NFS 194 V4 Call (Reply In 20) SEQUENCE
20 08:56:29.287994 192.168.122.129 192.168.122.158 NFS 150 V4 Reply (Call In 19) SEQUENCE
21 08:56:29.288038 192.168.122.158 192.168.122.129 NFS 346 V4 Call (Reply In 22) SETATTR FH: 0xf31a816b | DELEGRETURN StateID: 0xc2cb
22 08:56:29.290851 192.168.122.129 192.168.122.158 NFS 254 V4 Reply (Call In 21) SETATTR | DELEGRETURN
The server grants a WRITE_ATTRS_DELEG delegation on the OPEN and then
the client sets the delegated attrs and returns the delegation.
In the capture, the server sends the client an mtime/ctime of
1772113983:668837149 in the initial GETATTR after the create, but the
first fstat() of the file after the creat() shows the ctime to be later
than that. So, I think that is likely a bug.
Those times then don't change after utimensat() like they should, which
makes the test fail. This seems like a different bug.
ISTM that the client needs to do an on the wire SETATTR call to set the
atime in this case, even though it has a delegation, or else the ctime
won't end up being correct.
The new delegated attributes don't give us a way to tell the server to
only update the ctime and not the mtime, unfortunately, which is what
we'd need to do to handle utimensat() properly.
---------------------------------8<---------------------------------
generic/751:
This one seems fairly straightforward. The client does a REMOVEXATTR
while holding an attribute delegation, and the ctime isn't updated.
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 it seems like one probably just needs to be added
to REMOVEXATTR:
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
Alternately, I guess we could mark the attributes as bogus after a REMOVEXATTR. 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>
[-- Attachment #2: nfs-generic221.pcapng.gz --]
[-- Type: application/x-pcapng, Size: 1756 bytes --]
reply other threads:[~2026-03-02 19:04 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=c4dcc644fa65036f9bcae63e64b66509db85efc1.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=anna@kernel.org \
--cc=chuck.lever@oracle.com \
--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