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

Andy Isaacson commented on HDFS-2554:
-------------------------------------

bq. Wrt CorruptBlocksRN as long as we can distinguish between a block with all 
corrupt replicas and some corrupt replicas we're good.

If a block has a non-corrupt replica then n>0 and it's not counted here at all. 
 For example r=3 n=1 c=2 is a replication-3 block with two corrupt replicas and 
one valid replica.  Such a block is not counted in any of the 4 new metrics.

In this example, the 2 corrupt replicas are counted in the legacy 
{{CorruptBlocks}} metric which, as previously discussed, is the number of 
corrupt *replicas*.  (Not the number of corrupt *blocks* which the name 
implies.)

bq. Probably best at this point to just code up a patch with your proposal.

Am doing. :)
                
> Add separate metrics for missing blocks with desired replication level 1
> ------------------------------------------------------------------------
>
>                 Key: HDFS-2554
>                 URL: https://issues.apache.org/jira/browse/HDFS-2554
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: name-node
>    Affects Versions: 2.0.0-alpha
>            Reporter: Todd Lipcon
>            Assignee: Andy Isaacson
>            Priority: Minor
>
> Some users use replication level set to 1 for datasets which are unimportant 
> and can be lost with no worry (eg the output of terasort tests). But other 
> data on the cluster is important and should not be lost. It would be useful 
> to separate the metric for missing blocks by the desired replication level of 
> those blocks, so that one could ignore missing blocks at repl 1 while still 
> alerting on missing blocks with higher desired replication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to