[ 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)