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

User quota problem after Lustre upgrade (2.1.4 to 2.4.1)

Details

    • Bug
    • Resolution: Fixed
    • Major
    • None
    • Lustre 2.4.1
    • None
    • 3
    • 12320

    Description

      After the upgrade at KIT, the user quotas are not reported correctly. The quota for root seems to be OK. The user quota is 0 on all OSTs, which is wrong.

      e.g for root:

      [root@pfs2n13 ~]# lfs quota -u root -v /lustre/pfs2wor2/client/
      Disk quotas for user root (uid 0):
      Filesystem kbytes quota limit grace files quota limit
      grace
      /lustre/pfs2wor2/client/
      4332006768 0 0 - 790 0
      0 -
      pfs2wor2-MDT0000_UUID
      2349176 - 0 - 790 - 0
      -
      pfs2wor2-OST0000_UUID
      134219820 - 0 - - -

      • -
        pfs2wor2-OST0001_UUID
        12 - 0 - - - -
        -
        pfs2wor2-OST0002_UUID
        134219788 - 0 - - -
      • -

      for a user
      [root@pfs2n3 ~]# lfs quota -v -u aj9102 /lustre/pfs2wor1/client/
      Disk quotas for user aj9102 (uid 3522):
      Filesystem kbytes quota limit grace files quota limit
      grace
      /lustre/pfs2wor1/client/
      448 0 0 - 3985 0 0
      -
      pfs2wor1-MDT0000_UUID
      448 - 0 - 3985 - 0
      -
      pfs2wor1-OST0000_UUID
      0 - 0 - - - -
      -
      pfs2wor1-OST0001_UUID
      0 - 0 - - - -
      -
      pfs2wor1-OST0002_UUID
      0 - 0 - - - -
      -

      Attachments

        Issue Links

          Activity

            [LU-4504] User quota problem after Lustre upgrade (2.1.4 to 2.4.1)
            mdiep Minh Diep added a comment -

            Thank you Sir!

            mdiep Minh Diep added a comment - Thank you Sir!

            Yes, a long time ago. Please close. Thanks!

            orentas Oz Rentas (Inactive) added a comment - Yes, a long time ago. Please close. Thanks!
            mdiep Minh Diep added a comment -

            rganesan@ddn.com, orentas, have you resolved this issue? do you need anything else from this ticket?

            mdiep Minh Diep added a comment - rganesan@ddn.com , orentas , have you resolved this issue? do you need anything else from this ticket?

            We dont think manually fixing the OST object is not a good idea. Since the filesystem have more than 100 million files.
            Cu is expecting a better way to fix this issue,

            I can't think of any other good ways to fix the bad IDs. I think running a script instead of repeating the commands manually would be better?

            niu Niu Yawei (Inactive) added a comment - We dont think manually fixing the OST object is not a good idea. Since the filesystem have more than 100 million files. Cu is expecting a better way to fix this issue, I can't think of any other good ways to fix the bad IDs. I think running a script instead of repeating the commands manually would be better?

            Hello Niu,

            We dont think manually fixing the OST object is not a good idea. Since the filesystem have more than 100 million files.
            Cu is expecting a better way to fix this issue,

            Thanks,
            Rajesh

            rganesan@ddn.com Rajeshwaran Ganesan added a comment - Hello Niu, We dont think manually fixing the OST object is not a good idea. Since the filesystem have more than 100 million files. Cu is expecting a better way to fix this issue, Thanks, Rajesh

            I updated the way of how to fix bad ID for OST object (see my previous comment). Thanks.

            niu Niu Yawei (Inactive) added a comment - I updated the way of how to fix bad ID for OST object (see my previous comment). Thanks.

            People

              niu Niu Yawei (Inactive)
              orentas Oz Rentas (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: