You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "Siyao Meng (Jira)" <ji...@apache.org> on 2020/11/10 20:17:00 UTC

[jira] [Commented] (HDFS-15607) Create trash dir when allowing snapshottable dir

    [ https://issues.apache.org/jira/browse/HDFS-15607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229496#comment-17229496 ] 

Siyao Meng commented on HDFS-15607:
-----------------------------------

Note this jira has an addendum patch that fixes a small bug where disallowsnapshot() throws a different exception than before when called on a *file*. To learn more, see the description for [PR#2448|https://github.com/apache/hadoop/pull/2448].

> Create trash dir when allowing snapshottable dir
> ------------------------------------------------
>
>                 Key: HDFS-15607
>                 URL: https://issues.apache.org/jira/browse/HDFS-15607
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: hdfs
>    Affects Versions: 3.4.0
>            Reporter: Siyao Meng
>            Assignee: Siyao Meng
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 3.4.0
>
>          Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> 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?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org