On Tue, 2025-07-22 at 15:51 -0400, Trond Myklebust wrote: > On Tue, 2025-07-22 at 15:27 -0400, Jeff Layton wrote: > > I've been chasing some problems with the git regression testsuite > > that > > crop up with delegated timestamps enabled. I've knocked down a couple > > of problems on the server side, but I'm not sure how to fix the > > latest > > issue. > > > > Most of the problems with gitr suite and delegated timestamps > > manifest > > as spurious changes to the timestamps. e.g., it will do a git > > checkout > > and then later find that some file in the checkout appears to have > > changed when it didn't expect that. > > > > I reproduced one of the problems with some debugging turned up. What > > we > > see is this in the wireshark capture (filtered on the filehandle): > > > > 939238 1753209666.985827 192.168.122.151 → 192.168.122.103 NFS 486 V4 > > Reply (Call In 939237) OPEN StateID: 0xafa9 > > 939239 1753209666.987808 192.168.122.103 → 192.168.122.151 NFS 298 V4 > > Call SETATTR FH: 0x68fcd843 > > 939240 1753209666.995860 192.168.122.151 → 192.168.122.103 NFS 294 V4 > > Reply (Call In 939239) SETATTR > > 939241 1753209666.999909 192.168.122.103 → 192.168.122.151 NFS 278 V4 > > Call WRITE StateID: 0xe7e8 Offset: 0 Len: 2 > > 939242 1753209667.019570 192.168.122.151 → 192.168.122.103 NFS 182 V4 > > Reply (Call In 939241) WRITE > > 944922 1753209696.313938 192.168.122.103 → 192.168.122.151 NFS 1514 > > V4 Call SETATTR FH: 0xb6dd63b6 | DELEGRETURN StateID: 0x3eebV4 Call > > SETATTR FH: 0xcf57bbcb | DELEGRETURN StateID: 0x69ca ; V4 Call > > SETATTR FH: 0x68fcd843 | DELEGRETURN StateID: 0xe245 ; V4 Call > > SETATTR FH: 0x02d757ea | DELEGRETURN StateID: 0xc788 ; V4 Call > > SETATTR FH: 0x130870b2 | DELEGRETURN StateID: 0x8c12 > > 946410 1753209702.893917 192.168.122.103 → 192.168.122.151 NFS 254 V4 > > Call GETATTR FH: 0x68fcd843 > > 946411 1753209702.895304 192.168.122.151 → 192.168.122.103 NFS 310 V4 > > Reply (Call In 946410) GETATTR > > > > We get an open for write (with no open stateid and delegated > > timestamps), a write, and then and setattr|delegreturn. git had the > > delegated mtime (1753209666.995071118) on file because the delegation > > allowed getattr() on the client to return before writeback had > > completed. > > > > In this case, the setattr for the delegated mtime was for a value > > older > > than the existing mtime, so it was ignored. Note that the reply to > > Uhh... Why is the existing value of the mtime on the server grounds for > rejecting the delegated mtime? The client owns that value. >