[
https://issues.apache.org/jira/browse/HADOOP-10919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14096358#comment-14096358
]
Charles Lamb commented on HADOOP-10919:
---------------------------------------
bq. Q. when you say "distcp /r/r/src /r/r/dest" are the keys read from src and
preserved in the dest? Does the act of copying the keys from a /r/r/src into a
/r/r/dest automatically set up a matching EZ in the destination?
Yes to the first question and no to the second. Copying the keys occurs and
that is almost good enough to set up a matching EZ. However, what doesn't
happen is a call to createEncryptionZone so there is not an actual EZ in place
on the dst. The admin is expected to have done that before the distcp. If the
admin wants a parallel EZ (i.e. with the same keys, ez-key, etc.) -- and
presumably they do because they're copying from /.r/r to /.r/r and preserving
the keys along the way (this is my case "(a)" above) -- then it is also
expected that if the dest NN is not the same as the src (likely) that the NN
and the clients accessing that NN will have equal access to the KMS (presumably
the same KMS is shared across src and dst).
Does this make sense?
> Copy command should preserve raw.* namespace extended attributes
> ----------------------------------------------------------------
>
> Key: HADOOP-10919
> URL: https://issues.apache.org/jira/browse/HADOOP-10919
> Project: Hadoop Common
> Issue Type: Bug
> Components: fs
> Affects Versions: 3.0.0
> Reporter: Charles Lamb
> Assignee: Charles Lamb
> Fix For: fs-encryption (HADOOP-10150 and HDFS-6134)
>
> Attachments: HADOOP-10919.001.patch, HADOOP-10919.002.patch
>
>
> Refer to the doc attached to HDFS-6509 for background.
> Like distcp -p (see MAPREDUCE-6007), the copy command also needs to preserve
> extended attributes in the raw.* namespace by default whenever the src and
> target are in /.reserved/raw. To not preserve raw xattrs, don't specify
> /.reserved/raw in either the src or target.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
