[LU-13578] sanity test_39r: atime on client != ost Created: 18/May/20 Updated: 19/Dec/23 Resolved: 21/May/22 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.14.0 |
| Fix Version/s: | Lustre 2.14.0, Lustre 2.15.0 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Maloo | Assignee: | John Hammond |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||||||
| Severity: | 3 | ||||||||||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||||||||||
| Description |
|
This issue was created by maloo for S Buisson <sbuisson@ddn.com> This issue relates to the following test suite run: https://testing.whamcloud.com/test_sets/ec17386d-cefc-4749-9b51-1570a2c15729 test_39r failed with the following error: atime on client 1589573245 != ost 0x5ebef67c Very few additional information available: OST atime: atime: 0x5ebef67c:00000000 -- Fri May 15 20:07:24 2020 sanity test_39r: @@@@@@ FAIL: atime on client 1589573245 != ost 0x5ebef67c VVVVVVV DO NOT REMOVE LINES BELOW, Added by Maloo for auto-association VVVVVVV |
| Comments |
| Comment by Andreas Dilger [ 29/Jul/20 ] |
|
Saw this again on master: atime on client 1595930572 != ost 0x5f1ff7cb Again the OST timestamp was out by 1s. It may be that there is some kind of race, or the 1s granularity of the clocks makes the test fail some small fraction of time? This is failing about once every 3 days (9x in the past 4 weeks). Not critical, but it might be nice to understand it better: |
| Comment by Bruno Faccini (Inactive) [ 11/Oct/20 ] |
|
+1 on recent master at https://testing.whamcloud.com/test_sets/999472ce-8888-4fcd-bc47-7210a11127f6 |
| Comment by Andreas Dilger [ 14/Oct/20 ] |
|
+1 on master https://testing.whamcloud.com/test_sets/c9dca577-ca19-4ebb-8275-17d37fcdf09a |
| Comment by John Hammond [ 02/Nov/20 ] |
|
Copied over from Note that 0x5f9a449d == 1603945629 and that since the test uses (( ... )) this is not due to a difference of base. This may be from a final read() done by dd which returns no bytes and does not generate a BRW RPC to the OST. Even though it returns 0 bytes, it requested a non-zero number of bytes and is therefore required to update the file access time. |
| Comment by Gerrit Updater [ 15/Dec/20 ] |
|
John L. Hammond (jhammond@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/40973 |
| Comment by Andreas Dilger [ 16/Jan/21 ] |
|
+1 on master https://testing.whamcloud.com/test_sets/7f189347-052c-4c16-897f-cf26a3c17114 |
| Comment by Gerrit Updater [ 27/Jan/21 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/40973/ |
| Comment by Peter Jones [ 27/Jan/21 ] |
|
Landed for 2.14 |
| Comment by Alexander Zarochentsev [ 28/May/21 ] |
|
I am still seeing it: and there are more: Reopen? |
| Comment by Serguei Smirnov [ 20/Jul/21 ] |
|
+1 on master: https://testing.whamcloud.com/test_sets/c8e6816e-9641-4929-8ffd-d2505b6df743 |
| Comment by Gerrit Updater [ 13/May/22 ] |
|
"John L. Hammond <jhammond@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/47346 |
| Comment by Gerrit Updater [ 18/May/22 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/47346/ |