[
https://issues.apache.org/jira/browse/HDFS-15689?focusedWorklogId=513528&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-513528
]
ASF GitHub Bot logged work on HDFS-15689:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 18/Nov/20 12:08
Start Date: 18/Nov/20 12:08
Worklog Time Spent: 10m
Work Description: bshashikant commented on a change in pull request #2472:
URL: https://github.com/apache/hadoop/pull/2472#discussion_r526035428
##########
File path:
hadoop-hdfs-project/hadoop-hdfs-client/src/main/java/org/apache/hadoop/hdfs/client/HdfsAdmin.java
##########
@@ -171,7 +174,15 @@ public void clearQuotaByStorageType(Path src, StorageType
type) throws IOExcepti
public void allowSnapshot(Path path) throws IOException {
dfs.allowSnapshot(path);
if (dfs.isSnapshotTrashRootEnabled()) {
- dfs.provisionSnapshotTrash(path, TRASH_PERMISSION);
+ try {
+ dfs.provisionSnapshotTrash(path, TRASH_PERMISSION);
+ } catch (FileAlreadyExistsException ex) {
+ // Don't throw on FileAlreadyExistsException since it is likely due to
+ // admin allowing snapshot on an EZ root.
+ LOG.warn(ex.getMessage());
Review comment:
I think there are 2 approaches instead of just ignoring the
FileAlreadyExists exception:
1) we can just validate whether the existing Trash path is a directory and
validate the permissions and not throw FileAlreadyExists exception itself in
DistributedFileSystem.java#provisionSnapshotTrash
2) If the trash path already exists with right permissions, we can check if
the path is an encryption zone as well and throw FileAlreadyExists exception
only if its not an encryption zone. Similar change will be required for making
an snapshottable dir an encryption zone.
I am ok with either of the above approaches. I think just ignoring the
exception here will not work in case. the existing path is not a directory or
has right permissions.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 513528)
Time Spent: 20m (was: 10m)
> allow/disallowSnapshot on EZ roots shouldn't fail due to trash
> provisioning/emptiness check
> -------------------------------------------------------------------------------------------
>
> Key: HDFS-15689
> URL: https://issues.apache.org/jira/browse/HDFS-15689
> 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
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
