hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wellington Chevreuil (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-11197) Listing encryption zones fails when deleting a EZ that is on a snapshotted directory
Date Wed, 07 Dec 2016 12:26:58 GMT

    [ https://issues.apache.org/jira/browse/HDFS-11197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15728643#comment-15728643

Wellington Chevreuil commented on HDFS-11197:

I'm not sure this {{org.apache.hadoop.hdfs.TestEncryptionZones.testStartFileRetry}} test failure
is actually related. There were no changes to the actual fix between the last two patches,
and the test is passing on my local build:

Test set: org.apache.hadoop.hdfs.TestEncryptionZones
Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 46.25 sec - in org.apache.hadoop.hdfs.TestEncryptionZones

> Listing encryption zones fails when deleting a EZ that is on a snapshotted directory
> ------------------------------------------------------------------------------------
>                 Key: HDFS-11197
>                 URL: https://issues.apache.org/jira/browse/HDFS-11197
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: hdfs
>    Affects Versions: 2.6.0
>            Reporter: Wellington Chevreuil
>            Assignee: Wellington Chevreuil
>            Priority: Minor
>         Attachments: HDFS-11197-1.patch, HDFS-11197-2.patch, HDFS-11197-3.patch, HDFS-11197-4.patch,
HDFS-11197-5.patch, HDFS-11197-6.patch, HDFS-11197-7.patch
> If a EZ directory is under a snapshotable directory, and a snapshot has been taking,
then if this EZ is permanently deleted, it causes *hdfs crypto listZones* command to fail
without showing any of the still available zones.
> This happens only after the EZ is removed from Trash folder. For example, considering
*/test-snap* folder is snapshotable and there is already an snapshot for it:
> {noformat}
> $ hdfs crypto -listZones
> /user/systest           my-key
> /test-snap/EZ-1       my-key
> $ hdfs dfs -rmr /test-snap/EZ-1
> INFO fs.TrashPolicyDefault: Moved: 'hdfs://ns1/test-snap/EZ-1' to trash at: hdfs://ns1/user/hdfs/.Trash/Current/test-snap/EZ-1
> $ hdfs crypto -listZones
> /user/systest           my-key
> /user/hdfs/.Trash/Current/test-snap/EZ-1  my-key 
> $ hdfs dfs -rmr /user/hdfs/.Trash/Current/test-snap/EZ-1
> Deleted /user/hdfs/.Trash/Current/test-snap/EZ-1
> $ hdfs crypto -listZones
> RemoteException: Absolute path required
> {noformat}
> Once this error happens, *hdfs crypto -listZones* only works again if we remove the snapshot:
> {noformat}
> $ hdfs dfs -deleteSnapshot /test-snap snap1
> $ hdfs crypto -listZones
> /user/systest           my-key
> {noformat}
> If we instead delete the EZ using *skipTrash* option, *hdfs crypto -listZones* does not
> {noformat}
> $ hdfs crypto -listZones
> /user/systest           my-key
> /test-snap/EZ-2  my-key
> $ hdfs dfs -rmr -skipTrash /test-snap/EZ-2
> Deleted /test-snap/EZ-2
> $ hdfs crypto -listZones
> /user/systest           my-key
> {noformat}
> The different behaviour seems to be because when removing the EZ trash folder, it's related
INode is left with no parent INode. This causes *EncryptionZoneManager.listEncryptionZones*
to throw the seen error, when trying to resolve the inodes in the given path.
> Am proposing a patch that fixes this issue by simply performing an additional check on
*EncryptionZoneManager.listEncryptionZones* for the case an inode has no parent, so that it
would be skipped on the list without trying to resolve it. Feedback on the proposal is appreciated.


This message was sent by Atlassian JIRA

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

View raw message