[LU-13374] open-close operation can lead to loss of file time set performed in the middle

• Type: Bug
• Resolution: Fixed
• Priority: Major
• Fix Version/s: Lustre 2.16.0
• Assignee: Vitaly Fertman
• Reporter: Vitaly Fertman

Description

the original request in LU-12026 was to update *time as a part of LSOM update, i.e. to be stored in LSOM ea, but implemented as a regular time update on close, what is obviously wrong because it breaks set-in-past functionality (and in general due to the reasons we have LSOM but not SOM) - close always sends *time but does not bother accurately re-gather them from servers, while the local cache could be already stale. in other words this will not work:
1. client1 open
2. client2 set-in-past
3. client1 close

the reproducer is attached:

— set-in-past on opened file
File: '/mnt/lustre/f26c.sanityn'
Modify: 2020-03-19 22:31:05.000000000 +0300
File: '/mnt/lustre2/f26c.sanityn'
Modify: 2020-03-19 22:31:05.000000000 +0300

— set-in-past on closed file
File: '/mnt/lustre/f26c.sanityn'
Modify: 2000-12-31 14:12:59.000000000 +0300
File: '/mnt/lustre2/f26c.sanityn'
Modify: 2000-12-31 14:12:59.000000000 +0300

Issue Links

• is duplicated by: LU-17997 'scp -p' command cannot preserve mtime on nfs mounted lustre
• is related to: LU-12026 verify that MDS stores atime/mtime/ctime during LSOM update

Comments

[Peter Jones]

Merged for 2.16

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/54450/
Subject: LU-13374 mdd: fix close time update race with set-in-past
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: bcb954c1403fb1c0fed2ae1d4ed817e59a93a0b7

[Gerrit Updater]

"Vitaly Fertman <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/54450
Subject: LU-13374 mdd: fix close time update race with set-in-past
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: fb50062d86f6ed215fbfe8ed20a010e99a8b92b8

[Vitaly Fertman]

ah, it seems to be not so complex

[Vitaly Fertman]

I think this is what we want? If no size change, then LSOM would not be updated and set-in-past would be kept?

yes, set-in-past problem would be fixed. however, in this case for the first update on close, size will be changed from 0 to the actual one. if no more size changes - no more timestamps updated on any close. i.e. the purpose of LU-12026 will be mostly lost. Or was it added only for a simplification of size change detection? the ticket does not explain the purpose well enough...