https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-8531 Lustre <p>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.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">oslic2 ~&gt; 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 </pre> </div></div> lustre-2.5.5-6chaos_2.6.32_573.26.1.1chaos.ch5.4.x86_64.x86_64 LU-8531

Times on lustre filesystem are wrong and won't update

Bug Minor Resolved Won't Fix Niu Yawei Teresa Kamakea llnl Wed, 24 Aug 2016 00:04:44 +0000 Mon, 21 Nov 2016 03:08:01 +0000 Mon, 21 Nov 2016 03:08:01 +0000 Lustre 2.5.0 0 4 <p>Niu</p> <p>Could you please assist with this issue?</p> <p>Thanks</p> <p>Peter</p> <p>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 <a href="https://jira.whamcloud.com/browse/LU-6137" title="Update timestamps arbitrarily on MDS" class="issue-link" data-issue-key="LU-6137"><del>LU-6137</del></a>, but we kept the original policy at the end for safety.</p> <p>I think there are two ways to workaround this problem:<br/> 1. mount mdt as local filesystem and change the timestamps to correct time by 'touch';<br/> 2. choose a client and change it's sys time to future time (ahead of 2248-08-12), then set correct timestamps by 'touch';</p> <p>Thanks! Our team will be reviewing these options this afternoon.</p> <p>Decided that the risk is not worth implementing a work around since this does not affect users.</p> Development Rank 1|hzylwn: Rank (Obsolete) 9223372036854775807 Severity