[
https://issues.apache.org/jira/browse/HDFS-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635236#comment-15635236
]
Xiao Chen commented on HDFS-10899:
----------------------------------
Thanks Andrew for taking the time to look at this, and great comments! Really
appreciate it. I will accommodate them into the next patch.
A little clarifications first:
bq. LinkedHashMap v.s. ConcurrentLinkedDeque ... is there actually concurrency
happening?
I thought of this too. Currently there's just the single background thread in
the executor to process it. But later we likely want to multi-thread that for
performance. Also, we don't use the value (just the key) of the LinkedHashMap.
OTOH, I agree not using the deque nature is also bad...
Also thought about {{hasZone}} being O(n), but thought it's okay since it's not
a usual operation (only when new command submission / NN startup). Really wish
there's a concurrent linked hash set.... or at least a linked hash set..
bq. Can the new methods in EZManager be encapsulated as a class?
You mean to have a separate class for the background thread right? Surely can
do.
> Add functionality to re-encrypt EDEKs.
> --------------------------------------
>
> Key: HDFS-10899
> URL: https://issues.apache.org/jira/browse/HDFS-10899
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: encryption, kms
> Reporter: Xiao Chen
> Assignee: Xiao Chen
> Attachments: HDFS-10899.wip.patch, Re-encrypt edek design doc.pdf
>
>
> Currently when an encryption zone (EZ) key is rotated, it only takes effect
> on new EDEKs. We should provide a way to re-encrypt EDEKs after the EZ key
> rotation, for improved security.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
