[ https://issues.apache.org/jira/browse/HDFS-13281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16416212#comment-16416212 ]
Xiao Chen commented on HDFS-13281: ---------------------------------- Still don't understand the use cases, please help me understand. I played with distcp a little bit, IIUC this is an optimization for that scenario so that the extra EDEK doesn't get generated unnecessarily. How does HDFS-12597 use it? From [this comment|https://issues.apache.org/jira/browse/HDFS-12574?focusedCommentId=16329149&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16329149] client will still create the file in NN, only the streaming part will write encrypted data to DN, right? bq. /.reserved/raw is a special path prefix and you should be very careful to use it and not use irresponsibly. Exactly. Instead of educating every user when they raise an issue, can we proactively prevent this? How are we planning to set the EDEKs after a /.reserved/raw file is created? 1 atomic RPC to startFile with a user-provided edek feels safer, but messier to do.... > Namenode#createFile should be /.reserved/raw/ aware. > ---------------------------------------------------- > > Key: HDFS-13281 > URL: https://issues.apache.org/jira/browse/HDFS-13281 > Project: Hadoop HDFS > Issue Type: Bug > Components: encryption > Affects Versions: 2.8.3 > Reporter: Rushabh S Shah > Assignee: Rushabh S Shah > Priority: Critical > Attachments: HDFS-13281.001.patch > > > If I want to write to /.reserved/raw/<dir> and if that directory happens to > be in EZ, then namenode *should not* create edek and just copy the raw bytes > from the source. > Namenode#startFileInt should be /.reserved/raw/ aware. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org