[HDFS-15689] allow/disallowSnapshot on EZ roots shouldn't fail due to trash provisioning/emptiness check

• Type: Sub-task
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.4.0
• Fix Version/s: 3.4.0
• Component/s: hdfs
• Labels: pull-request-available
• Target Version/s: 3.4.0
• Hadoop Flags: Reviewed
• Assignee: Siyao Meng
• Reporter: Siyao Meng
• Created: 18/Nov/20 10:24
• Updated: 27/Jan/24 02:57
• Resolved: 03/Dec/20 19:22

Description

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

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).

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.

Issue Links

• fixes: HDFS-15687 allowSnapshot fails when directory already has a Trash sub directory
• is caused by: HDFS-15539 When disallowing snapshot on a dir, throw exception if its trash root is not empty
• is caused by: HDFS-15607 Create trash dir when allowing snapshottable dir
• links to: GitHub Pull Request #2472