[jira] [Created] (HDFS-15689) allow/disallowSnapshot on EZ roots shouldn't fail due to trash root provisioning or emptiness check

["Siyao Meng (Jira)" <ji...@apache.org>]

Siyao Meng created HDFS-15689:
---------------------------------

             Summary: allow/disallowSnapshot on EZ roots shouldn't fail due to trash root provisioning or emptiness check
                 Key: HDFS-15689
                 URL: https://issues.apache.org/jira/browse/HDFS-15689
             Project: Hadoop HDFS
          Issue Type: Bug
          Components: hdfs
    Affects Versions: 3.4.0
            Reporter: Siyao Meng
            Assignee: Siyao Meng


h2. Background

1. HDFS-15607 added a feature that when {{dfs.namenode.snapshot.trashroot.enabled=true}}, allowSnapshot will automatically create a .Trash directory immediately after allowSnapshot operation so files deleted will be moved into the trash root inside the snapshottable directory.
2. HDFS-15539 prevents admins from disallowing snapshot if the trash root inside is not empty

h2. Problem

1. When {{dfs.namenode.snapshot.trashroot.enabled=true}}, currently if the directory (to be allowed snapshot on) is an EZ root, it throws {{FileAlreadyExistsException}} because the trash root already exists (encryption zone has already created an internal trash root).
2. Similarly, at the moment if we disallow snapshot on an EZ root, it may complain that the trash root is not empty (or delete it if empty, which is not desired since EZ will still need it).

h2. Solution

1. Let allowSnapshot succeed by not throwing {{FileAlreadyExistsException}}, but informs the admin that the trash already exists.
2. Ignore {{checkTrashRootAndRemoveIfEmpty()}} check if path is EZ root.



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

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