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-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
