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] [Updated] (HDFS-11197) Listing encryption zones fails when deleting a EZ that is on a snapshotted directory
Date Fri, 02 Dec 2016 09:30:58 GMT

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

Wellington Chevreuil updated HDFS-11197:
----------------------------------------
    Attachment: HDFS-11197-3.patch

For some reason, the changes I mentioned on my previous comment were not included in the last
patch. Including a 3rd patch with the fix for the test and the additional unit test for checking
this condition on TestEncryptionZoneManager.

The findbugs warning does not seem related to any of the changes from this patch.

> 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
>
>
> 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
break:
> {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
(v6.3.4#6332)

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


Mime
View raw message