Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 25 Aug 2017 16:34:01 +0000 (UTC)
From: "Wellington Chevreuil (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.13096718.1503405134000.121972.1503678841779@Atlassian.JIRA>
In-Reply-To: <JIRA.13096718.1503405134000@Atlassian.JIRA>
References: <JIRA.13096718.1503405134000@Atlassian.JIRA> <JIRA.13096718.1503405134403@jira-lw-us.apache.org>
Subject: [jira] [Updated] (HDFS-12336) Listing encryption zones still fails
 when deleted EZ is not a direct child of snapshottable directory
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 25 Aug 2017 16:34:10 -0000


     [ https://issues.apache.org/jira/browse/HDFS-12336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wellington Chevreuil updated HDFS-12336:
----------------------------------------
    Attachment: HDFS-12336.003.patch

Thanks for the suggestions [~xiaochen]! Indeed, checking the absolute path is much simpler. I thought of defining a new helper method, *isValidAbsolutePath* on *INode* class that does the check previously done on *checkAbsolutePath*, then using this new one on *EncryptionZoneManager.listEncryptionZones* to determine if the inode should be filtered or not.

Also had applied the suggestions to *EncryptionZonesTest*, had added javadoc explaining why we need to move to Trash first, instead of simply deleting it, and also removed the calls to assertZonePresent.

I also noticed latest patch was out of sync with trunk. I had rebased it to latest trunk version and had resolved some conflicts with HDFS-10899, which has doe a large refactoring in EncryptionZoneManager. These scenario was still failing, though.

> Listing encryption zones still fails when deleted EZ is not a direct child of snapshottable directory
> -----------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-12336
>                 URL: https://issues.apache.org/jira/browse/HDFS-12336
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: hdfs
>    Affects Versions: 3.0.0-alpha4
>            Reporter: Wellington Chevreuil
>            Assignee: Wellington Chevreuil
>            Priority: Minor
>         Attachments: HDFS-12336.001.patch, HDFS-12336.002.patch, HDFS-12336.003.patch
>
>
> The fix proposed on HDFS-11197 didn't cover the scenario where the EZ deleted but still under a snapshot is not a direct child of the snapshottable directory.
> Here the code snippet proposed on HDFS-11197 that would avoid the error reported by *hdfs crypto -listZones* when a deleted EZ is still under a given snapshot:
> {noformat}
>       INode lastINode = null;
>       if (inode.getParent() != null || inode.isRoot()) {
>         INodesInPath iip = dir.getINodesInPath(pathName, DirOp.READ_LINK);
>         lastINode = iip.getLastINode();
>       }
>       if (lastINode == null || lastINode.getId() != ezi.getINodeId()) {
>         continue;
>       }
> {noformat} 
> It will ignore EZs when it's a direct child of a snapshot, because its parent inode will be null, and it isn't the root inode. However, if the EZ is not directly under snapshottable directory, its parent will not be null, and it will pass this check, so it will fail further due *absolute path required* validation error.
> I would like to work on a fix that would also cover this scenario.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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