hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juan Yu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-5189) Rename the "CorruptBlocks" metric to "CorruptReplicas"
Date Tue, 29 Jul 2014 17:54:39 GMT

    [ https://issues.apache.org/jira/browse/HDFS-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078070#comment-14078070

Juan Yu commented on HDFS-5189:

[~qwertymaniac], "CorruptReplicas" could be misleading as well. The count is indeed per block.
If one Block has more than one corrupted replicas, it's counted just once in {{SortedMap<Block,
Map<DatanodeDescriptor, Reason>> corruptReplicasMap}} 
How about "CorruptReplBlocks"?

> Rename the "CorruptBlocks" metric to "CorruptReplicas"
> ------------------------------------------------------
>                 Key: HDFS-5189
>                 URL: https://issues.apache.org/jira/browse/HDFS-5189
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: namenode
>    Affects Versions: 2.1.0-beta
>            Reporter: Harsh J
>            Assignee: Juan Yu
>            Priority: Minor
> The NameNode increments a "CorruptBlocks" metric even if only one of the block's
> replicas is reported corrupt (genuine checksum fail, or even if a
> replica has a bad genstamp). In cases where this is incremented, fsck
> still reports a healthy state.
> This is confusing to users and causes false alarm as they feel this is to be monitored
(instead of MissingBlocks). The metric is truly trying to report only corrupt replicas, not
whole blocks, and ought to be renamed.
> FWIW, the "dfsadmin -report" reports a proper string of "Blocks with corrupt replicas:"
when printing this count.

This message was sent by Atlassian JIRA

View raw message