[
https://issues.apache.org/jira/browse/HDFS-9586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15067495#comment-15067495
]
Phil Yang commented on HDFS-9586:
---------------------------------
{quote}
So all the blocks that go into QUEUE_WITH_CORRUPT_BLOCKS already has zero
decommissioning replicas.
{quote}
In theory, I think it is right. However when decommissioning nodes there may be
false positives of block-missing error. It is another bug that I'm digging out.
I'm not sure why we need
{code}
if (inode != null && blockManager.countNodes(blk).liveReplicas() == 0)
{code}
in FSNamesystem.listCorruptFileBlocks, in theory the second condition should be
always true. But because of the bug, we need this condition indeed, so I think
we need another condition about decommissioning replicas.
> listCorruptFileBlocks should not output files that all replications are
> decommissioning
> ---------------------------------------------------------------------------------------
>
> Key: HDFS-9586
> URL: https://issues.apache.org/jira/browse/HDFS-9586
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Phil Yang
> Assignee: Phil Yang
> Attachments: 9586-v1.patch
>
>
> As HDFS-7933 said, we should count decommissioning and decommissioned nodes
> respectively and regard decommissioning nodes as special live nodes whose
> file is not corrupt or missing.
> So in listCorruptFileBlocks which is used by fsck and HDFS namenode website,
> we should collect a corrupt file only if liveReplicas and decommissioning are
> both 0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
