[
https://issues.apache.org/jira/browse/HDFS-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14167019#comment-14167019
]
Philip Zeyliger commented on HDFS-7165:
---------------------------------------
The code looks fine to me. Thanks!
I'm having trouble with the naming of {{getNumberOfMissingUnreplicatedBlocks}}
vs. {{getNumberOfMissingBlocks}}. Perhaps simply
{{getNumberOfMissingBlocksWithReplicationOne}}? I assume you're trying to say
that "unreplicated" means "is intended to not be replicated; had just that one
base copy," but the usage seems inconsistent. Of course, I'll defer to others
with more experience in this code base.
bq. + required uint64 missing_unreplicated_blocks = 7;
Does making this "required" in the protocol cause issues? It's obviously not
existed in previous versions, but it's desirable that new clients can discern
that this isn't set, and old clients continue to work.
> Separate block metrics for files with replication count 1
> ---------------------------------------------------------
>
> Key: HDFS-7165
> URL: https://issues.apache.org/jira/browse/HDFS-7165
> Project: Hadoop HDFS
> Issue Type: Improvement
> Reporter: Andrew Wang
> Assignee: Zhe Zhang
> Attachments: HDFS-7165-20141003-v1.patch, HDFS-7165-20141009-v1.patch
>
>
> We see a lot of escalations because someone has written teragen output with a
> replication factor of 1, a DN goes down, and a bunch of missing blocks show
> up. These are normally false positives, since teragen output is disposable,
> and generally speaking, users should understand this is true for all repl=1
> files.
> It'd be nice to be able to separate out these repl=1 missing blocks from
> missing blocks with higher replication factors..
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
