[
https://issues.apache.org/jira/browse/HDFS-7281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14511729#comment-14511729
]
Yongjun Zhang commented on HDFS-7281:
-------------------------------------
Thanks [~cnauroth] for his comment below
{quote}
Metrics/JMX is covered by our compatibility guidelines:
http://hadoop.apache.org/docs/r2.7.0/hadoop-project-dist/hadoop-common/Comp
atibility.html#MetricsJMX
Metrics/JMX is similar to our usage of Protocol Buffers/JSON that I
mentioned. It supports backwards-compatible evolution if the change is
done correctly. Adding new fields/beans is compatible. Changing the
names or data types of existing fields/beans is incompatible. Deleting
existing fields/beans is incompatible.
--Chris Nauroth
{quote}
> Missing block is marked as corrupted block
> ------------------------------------------
>
> Key: HDFS-7281
> URL: https://issues.apache.org/jira/browse/HDFS-7281
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Ming Ma
> Assignee: Ming Ma
> Labels: supportability
> Attachments: HDFS-7281-2.patch, HDFS-7281-3.patch, HDFS-7281-4.patch,
> HDFS-7281.patch
>
>
> In the situation where the block lost all its replicas, fsck shows the block
> is missing as well as corrupted. Perhaps it is better not to mark the block
> corrupted in this case. The reason it is marked as corrupted is
> numCorruptNodes == numNodes == 0 in the following code.
> {noformat}
> BlockManager
> final boolean isCorrupt = numCorruptNodes == numNodes;
> {noformat}
> Would like to clarify if it is the intent to mark missing block as corrupted
> or it is just a bug.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
