[
https://issues.apache.org/jira/browse/HDFS-8872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15235491#comment-15235491
]
Wei-Chiu Chuang commented on HDFS-8872:
---------------------------------------
Looking at the source code, I think there is a mismatch of understanding
between webui and fsck.
In webui, the missing blocks actually means the number of blocks that have no
replicas at all. (that is, the number of corrupt blocks); whereas in fsck, it
shows the difference between the expected replication and the available
replications.
More specifically, the webui gets the number from
{{FSNamesystem#getMissingBlocksCount}}, and this in turn calls
{{LowRedundancyBlocks#getCorruptBlockSize}}.
I think that to fix it, {{FSNamesystem#getMissingBlocksCount}} should not
return the number from {{LowRedundancyBlocks#getCorruptBlockSize}}. Instead, it
should derive the number in the same way as in
{{NamenodeFsck#collectBlocksSummary}}.
> Reporting of missing blocks is different in fsck and namenode ui/metasave
> -------------------------------------------------------------------------
>
> Key: HDFS-8872
> URL: https://issues.apache.org/jira/browse/HDFS-8872
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.6.0
> Reporter: Rushabh S Shah
> Assignee: Rushabh S Shah
>
> Namenode ui and metasave will not report a block as missing if the only
> replica is on decommissioning/decomissioned node while fsck will show it as
> MISSING.
> Since decommissioned node can be formatted/removed anytime, we can actually
> lose the block.
> Its better to alert on namenode ui if the only copy is on
> decomissioned/decommissioning node.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
