[
https://issues.apache.org/jira/browse/HDFS-12336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16139576#comment-16139576
]
Xiao Chen commented on HDFS-12336:
----------------------------------
Thanks [~wchevreuil] for reporting the issue and providing a patch.
It's not obvious to me what caused the error - IIUC getINodesInPath would throw
the absolute path required, but that path is constructed from getFullPathName
of the inode.
Also tried the tests, but the TestEZM is highly mocked, and TestCryptoAdminCLI
seems to pass with or without the fix. Since this part of code is mistaken a
few times, starting from HDFS-7078, to the mentioned HDFS-11197, I wonder if it
makes sense to do a real test in TestEncryptionZones? We could set up a
combination of snapshots, and verify the result of listing in 1 test case. IMO
this is more maintainable than mocking in TestEZM. We can start with the test
cases, and pursue the correct fix from there.
> 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
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
