Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-8531

Times on lustre filesystem are wrong and won't update

Details

    • Bug
    • Resolution: Won't Fix
    • Minor
    • None
    • Lustre 2.5.0
    • lustre-2.5.5-6chaos_2.6.32_573.26.1.1chaos.ch5.4.x86_64.x86_64
    • 4
    • 9223372036854775807

    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
      

      Attachments

        Activity

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

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

          kamakea1 Teresa Kamakea (Inactive) added a comment - Decided that the risk is not worth implementing a work around since this does not affect users.

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

          kamakea1 Teresa Kamakea (Inactive) added a comment - Thanks! Our team will be reviewing these options this afternoon.

          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';

          niu Niu Yawei (Inactive) added a comment - 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';
          pjones Peter Jones added a comment -

          Niu

          Could you please assist with this issue?

          Thanks

          Peter

          pjones Peter Jones added a comment - Niu Could you please assist with this issue? Thanks Peter

          People

            niu Niu Yawei (Inactive)
            kamakea1 Teresa Kamakea (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: