[LU-6137] Update timestamps arbitrarily on MDS Created: 20/Jan/15  Updated: 14/Jun/18  Resolved: 14/Aug/15

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.7.0
Fix Version/s: Lustre 2.8.0

Type: Bug Priority: Critical
Reporter: Niu Yawei (Inactive) Assignee: Niu Yawei (Inactive)
Resolution: Fixed Votes: 2
Labels: None

Issue Links:
Related
is related to LU-6087 sanity test_300b: mtime not change af... Resolved
is related to LU-7310 sanityn test_39a fails with 'mtime is... Resolved
Severity: 3
Rank (Obsolete): 17106

 Description   

There was a timestamps update policy on MDS: ctime is increasing
only, which means if the ctime to be updated is behind of current
inode->i_ctime, then this timestamps update will be rejected.

This policy sounds not reasonable and it could lead to following
problems:

1. If time isn't synced on clients, the file created by the client
having advanced clock will have advanced ctime, so any operations
from the client with lagging clock won't be able to update file
timestamps.

2. If the client clock is adjusted to a past time, then this client
won't be able to change timestamps to the already create files.

3. Server time could be used on inode->i_ctime if the client time
isn't provided for certain operation from some old version
client, and if the server time is ahead of client time, we'll
run into the same problem.

4. Sometime ldiskfs API may set server time on inode->i_ctime (
ext4 nomctime patch doesn't cover all cases), and it should be
overwritten by client time in upper layer (see
mdt_reint_setxattr()), however, because of the timestamps update
policy, the overwrite operation could fail if the server time
is ahead of client time.



 Comments   
Comment by Niu Yawei (Inactive) [ 20/Jan/15 ]

http://review.whamcloud.com/#/c/13396

Comment by Gerrit Updater [ 10/Feb/15 ]

Niu Yawei (yawei.niu@intel.com) uploaded a new patch: http://review.whamcloud.com/13705
Subject: LU-6137 ldiskfs: simplify nocmtime patch
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: fe5d5a9e3a65dd5ae4f777332c2804d5200d4d3d

Comment by Niu Yawei (Inactive) [ 10/Feb/15 ]

The patch above is split: http://review.whamcloud.com/13705 (fix ldiskfs nocmtime only).

Comment by Gerrit Updater [ 03/Mar/15 ]

Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/13705/
Subject: LU-6137 ldiskfs: simplify nocmtime patch
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: d2c828a32a3b019194051ee24607eafee517cc43

Comment by James A Simmons [ 03/Mar/15 ]

Patch has landed to master. Ticket can be closed.

Comment by Niu Yawei (Inactive) [ 04/Mar/15 ]

There are two patches tracked in this ticket, one is landed, another is still being reviewed, please keep it open.

Comment by Gerrit Updater [ 06/Mar/15 ]

Niu Yawei (yawei.niu@intel.com) uploaded a new patch: http://review.whamcloud.com/13994
Subject: LU-6137 ldiskfs: simplify nocmtime patch
Project: fs/lustre-release
Branch: b2_5
Current Patch Set: 1
Commit: 86b16e3251db5aa655edbce6f8b9a97651d79bb8

Comment by Andreas Dilger [ 18/Mar/15 ]

Could you please work on a conf-sanity test that changes the clocks on the MDS and OSS nodes, as described in LU-6087, so that we can find and fix this kind of problem more easily. They should try both setting either the MDS clock or OSS clock ahead of the client, and also behind the client clock.

Comment by Gerrit Updater [ 20/Mar/15 ]

Niu Yawei (yawei.niu@intel.com) uploaded a new patch: http://review.whamcloud.com/14122
Subject: LU-6137 test: Server time should not be used
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 3d2f13ab9fd49590934bb178d7dc7fb0bbc5b22c

Comment by Niu Yawei (Inactive) [ 20/Mar/15 ]

Add sanity test to verify that server time isn't used: http://review.whamcloud.com/14122

Comment by Niu Yawei (Inactive) [ 14/Aug/15 ]

The patch fixing ldiskfs is landed, which can fix customer's problem. The other two patches were abandoned.

Generated at Sat Feb 10 01:57:32 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.