[
https://issues.apache.org/jira/browse/HDFS-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15546748#comment-15546748
]
Kihwal Lee commented on HDFS-10939:
-----------------------------------
In {{startFileInt()}}, {{unlock()}} is done in {{getEncryptionKeyInfo()}} and
it is reacquired in {{startFileInt()}}. Is this asymmetry necessary? It looks
like {{getEncryptionKeyInfo()}} is supposed to be called with the write lock
anyway. Wouldn't it make more sense to make it reacquire the lock in its
finally block? Sure, it might incur extra lock-unlock if something fails: If
{{generateEncryptedDataEncryptionKey()}} fails, the lock will be reacquired
from {{getEncryptionKeyInfo()}}. Then release immediately in the finally block
of {{startFileInt()}}. Still I think it is better to organize locking this way
at the price of extra locking on rare failure cases. Correctness wise, the
patch seems fine.
> Reduce performance penalty of encryption zones
> ----------------------------------------------
>
> Key: HDFS-10939
> URL: https://issues.apache.org/jira/browse/HDFS-10939
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs
> Affects Versions: 2.7
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Attachments: HDFS-10939.1.patch, HDFS-10939.patch
>
>
> The encryption zone APIs should be optimized to extensively use IIPs to
> eliminate path resolutions. The performance penalties incurred by common
> operations like creation of file statuses may be reduced by more extensive
> short-circuiting of EZ lookups when no EZs exist. All file creates should
> not be subjected to the multi-stage locking performance penalty required only
> for EDEK generation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
