[
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
