[ https://issues.apache.org/jira/browse/HDFS-11197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15715910#comment-15715910 ]
Xiao Chen commented on HDFS-11197: ---------------------------------- Thanks for the prompt response Welllington. I was thinking about the whole scenarios in the description of this jira: create zone -> create snapshot -> remove dir -> list zone. Do you think it makes sense to add that? > 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 > > > 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-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org