Uploaded image for project: 'Hadoop HDFS'
  1. Hadoop HDFS
  2. HDFS-15477 Enforce ordered snapshot deletion
  3. HDFS-15607

Create trash dir when allowing snapshottable dir

    XMLWordPrintableJSON

    Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.4.0
    • Fix Version/s: 3.4.0
    • Component/s: hdfs
    • Target Version/s:

      Description

      In TrashPolicyDefault, the .Trash directory will be created with permission 700 (and without sticky bit) by the first user that moves a file to the trash. This is an issue when other users try to move files to that trash because they may not have the permission to move to that trash if the trash root is shared. – in this case, snapshottable directories.

      This only affects users when trash is enabled inside snapshottable directories (dfs.namenode.snapshot.trashroot.enabled set to true), and when a user performing move to trash operations doesn't have admin permissions.

      Solution: Create a .Trash directory with 777 permission and sticky bits enabled (similar solution as HDFS-10324).

      Also need to deal with some corner cases:

      1. even when the snapshottable directory trash root config is not enabled (dfs.namenode.snapshot.trashroot.enabled set to false), create the .Trash directory anyway? Or should we ask the admin to provision trash manually after enabling dfs.namenode.snapshot.trashroot.enabled on an existing cluster?

      • If the cluster is just upgraded, we need to provision trash manually anyway.

      2. When immediately disallowing trash, it shouldn't fail. just remove the .Trash directory when disallowing snapshot on a dir if it is empty?

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                smeng Siyao Meng
                Reporter:
                smeng Siyao Meng
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 2h 40m
                  2h 40m