Details
-
Bug
-
Resolution: Fixed
-
Critical
-
Lustre 2.7.0
-
None
-
3
-
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.
