Wellington Chevreuil created HDFS-11197:

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

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:

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

Once this error happens, *hdfs crypto -listZones* only works again if we remove 
the snapshot:

$ hdfs dfs -deleteSnapshot /test-snap snap1
$ hdfs crypto -listZones
/user/systest           my-key

If we instead delete the EZ using *skipTrash* option, *hdfs crypto -listZones" 
does not break:

$ 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

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