[
https://issues.apache.org/jira/browse/HDFS-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16652609#comment-16652609
]
Wei-Chiu Chuang commented on HDFS-8533:
---------------------------------------
I'm pretty sure I found the root cause of this bug: HDFS-13999. There's a
corner case where we don't decrement the corrupt block counter (but the block
is actually good)
> Mismatch in displaying the "MissingBlock" count in fsck and in other metric
> reports
> -----------------------------------------------------------------------------------
>
> Key: HDFS-8533
> URL: https://issues.apache.org/jira/browse/HDFS-8533
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.7.0
> Reporter: J.Andreina
> Assignee: J.Andreina
> Priority: Critical
>
> Number of DN = 2
> Step 1: Write a file with replication factor - 3 .
> Step 2: Corrupt a replica in DN1
> Step 3: DN2 is down.
> Missing Block count in report is as follows
> Fsck report : *0*
> Jmx, "dfsadmin -report" , UI, logs : *1*
> In fsck , only block whose replicas are all missed and not been corrupted are
> counted
> {code}
> if (totalReplicasPerBlock == 0 && !isCorrupt) {
> // If the block is corrupted, it means all its available replicas are
> // corrupted. We don't mark it as missing given these available
> replicas
> // might still be accessible as the block might be incorrectly marked
> as
> // corrupted by client machines.
> {code}
> While in other reports even if all the replicas are corrupted , block is been
> considered as missed.
> Please provide your thoughts : can we make missing block count consistent
> across all the reports same as implemented for fsck?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
