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 the WRITE didn't go out until 1753209667.019570, which is after 1753209666.995071118. Eventually the client gets the "real" mtime from the server after returning the delegation, which now doesn't match the one git has on file. I don't see a way to fix this right offhand. Any thoughts? -- Jeff Layton <jlayton@xxxxxxxxxx>
