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

Second patch with the checkstyle issues fixed for TestEncryptionZoneManager 
class. Apologies for not had ran checkstyles locally previously, had 
succesfully ran it now.

Also changed to comply the situation from the failed tests 
*org.apache.hadoop.hdfs.TestEncryptionZones* and 
*org.apache.hadoop.hdfs.TestEncryptionZonesWithKMS*, where the EZ is actually 
the root folder.

Added a 3rd unit test to cover this case. Tests are passing locally, now.

> 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
> 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

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

Reply via email to