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

Attempts to delete .lustre/ should fail with EPERM

Details

    • Bug
    • Resolution: Fixed
    • Blocker
    • Lustre 2.4.0
    • Lustre 2.4.0
    • 3
    • 6921

    Description

      On master, rm -rf $FSROOT/.lustre/ succeeds though it should (and used to) return EPERM.

      According to git bisect, the regression was introduced by change I7483b0f023e4e3de6597da58d3d9f3e96c0d53b7 (http://review.whamcloud.com/#change,4339)

      Attachments

        Activity

          [LU-2858] Attempts to delete .lustre/ should fail with EPERM
          pjones Peter Jones added a comment -

          Landed for 2.4

          pjones Peter Jones added a comment - Landed for 2.4
          di.wang Di Wang added a comment -

          http://review.whamcloud.com/#change,5555

          di.wang Di Wang added a comment - http://review.whamcloud.com/#change,5555
          di.wang Di Wang added a comment -

          Yes, I am working on the patch, the dot lustre and obf had a few other problem as well. I will post the fix soon. Thanks.

          di.wang Di Wang added a comment - Yes, I am working on the patch, the dot lustre and obf had a few other problem as well. I will post the fix soon. Thanks.
          hdoreau Henri Doreau (Inactive) added a comment - - edited

          The problem is that the aforementioned patch I7483b0f023e4e3de6597da58d3d9f3e96c0d53b7
          modified mdo_unlink() to make it call the corresponding method of the parent instead
          of the one of the child. Therefore, dot_lustre_mdd_unlink (that always return -EPERM)
          was never invoked.

          In the following patch, that fixes the issue, I've added a check to mdt_reint_unlink()
          to make sure that we not trying to unlink .lustre/

          See:
          http://review.whamcloud.com/#change,5544

          hdoreau Henri Doreau (Inactive) added a comment - - edited The problem is that the aforementioned patch I7483b0f023e4e3de6597da58d3d9f3e96c0d53b7 modified mdo_unlink() to make it call the corresponding method of the parent instead of the one of the child. Therefore, dot_lustre_mdd_unlink (that always return -EPERM) was never invoked. In the following patch, that fixes the issue, I've added a check to mdt_reint_unlink() to make sure that we not trying to unlink .lustre/ See: http://review.whamcloud.com/#change,5544
          pjones Peter Jones added a comment -

          Di

          Could you please look into this one?

          Thanks

          Peter

          pjones Peter Jones added a comment - Di Could you please look into this one? Thanks Peter

          People

            di.wang Di Wang
            hdoreau Henri Doreau (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: