[LU-8531] Times on lustre filesystem are wrong and won't update

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.5.0
• Type: Bug
• Priority: Minor
• Reporter: Teresa Kamakea
• Assignee: Niu Yawei (Inactive)
• Resolution: Won't Fix
• Labels: llnl

Environment

lustre-2.5.5-6chaos_2.6.32_573.26.1.1chaos.ch5.4.x86_64.x86_64

• Severity: 4

Description

After crashing the mds on the lustre file system lscratche, upon recovery it was found that the top level dates are wrong. Even after running chmod neither the Modify or Change times were updated.

oslic2 ~> stat /p/lscratche
 File: `/p/lscratche'
Size: 609792          Blocks: 1191       IO Block: 131072 directory
Device: 68756a28h/1752525352d   Inode: 144115188193296385  Links: 3912
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 1969-12-31 16:00:00.000000000 -0800
Modify: 1969-12-31 16:00:00.000000000 -0800
Change: 2248-08-12 09:46:20.000000000 -0700

Comments

[Peter Jones]

Niu

Could you please assist with this issue?

Thanks

Peter

[Niu Yawei (Inactive)]

Looks the timestamps of the directory is corrupted and the ctime is set to a future time. (2248-08-12) For some history reason, Lustre follows a policy that server will reject timestamps update if the request ctime is older than current server inode ctime, there was debate on such policy in LU-6137, but we kept the original policy at the end for safety.

I think there are two ways to workaround this problem:
1. mount mdt as local filesystem and change the timestamps to correct time by 'touch';
2. choose a client and change it's sys time to future time (ahead of 2248-08-12), then set correct timestamps by 'touch';

[Teresa Kamakea]

Thanks! Our team will be reviewing these options this afternoon.

[Teresa Kamakea]

Decided that the risk is not worth implementing a work around since this does not affect users.