[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... 

[Andreas Dilger]

Andreas, do I understand you right that your last proposal also means to extend LSOM by timestamps, correct? or by saying 'timestamps in LSOM' you still mean to update in the regular file attribute but only along when LSOM ea update?

I mean to keep the timestamps in the regular inode, but only when LSOM is updated because of size.

if no size change, no LSOM ea update, so the set-in-past would be dropped.

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