[
https://issues.apache.org/jira/browse/HDFS-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14705920#comment-14705920
]
Zhe Zhang commented on HDFS-8920:
---------------------------------
Thanks for performing the tests and reporting the issue [~lirui].
I agree with Colin. Changing the log level will affect non-EC I/O operations,
because in that case {{chosenNode == null}} does indicate a pretty high chance
of data loss. A non-ideal solution is to check whether {{block}} is striped
({{BlockIdManager#isStripedBlockID}} and then determine whether to warn or
debug. I'm OK with that solution for now.
> Erasure Coding: when recovering lost blocks, logs can be too verbose and hurt
> performance
> -----------------------------------------------------------------------------------------
>
> Key: HDFS-8920
> URL: https://issues.apache.org/jira/browse/HDFS-8920
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Rui Li
> Assignee: Rui Li
>
> When we test reading data with datanodes killed,
> {{DFSInputStream::getBestNodeDNAddrPair}} becomes a hot spot method and
> effectively blocks the client JVM. This log seems too verbose:
> {code}
> if (chosenNode == null) {
> DFSClient.LOG.warn("No live nodes contain block " + block.getBlock() +
> " after checking nodes = " + Arrays.toString(nodes) +
> ", ignoredNodes = " + ignoredNodes);
> return null;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
