[
https://issues.apache.org/jira/browse/HDFS-10858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15485405#comment-15485405
]
Andrew Wang commented on HDFS-10858:
------------------------------------
+1 LGTM, nice find Jing!
> FBR processing may generate incorrect reportedBlock-blockGroup mapping
> ----------------------------------------------------------------------
>
> Key: HDFS-10858
> URL: https://issues.apache.org/jira/browse/HDFS-10858
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: erasure-coding
> Affects Versions: 3.0.0-alpha1
> Reporter: Jing Zhao
> Assignee: Jing Zhao
> Priority: Blocker
> Attachments: HDFS-10858.000.patch
>
>
> In BlockManager#reportDiffSorted:
> {code}
> } else if (reportedState == ReplicaState.FINALIZED &&
> (storedBlock.findStorageInfo(storageInfo) == -1 ||
> corruptReplicas.isReplicaCorrupt(storedBlock, dn))) {
> // Add replica if appropriate. If the replica was previously corrupt
> // but now okay, it might need to be updated.
> toAdd.add(new BlockInfoToAdd(storedBlock, replica));
> }
> {code}
> "new BlockInfoToAdd(storedBlock, replica)" is wrong because "replica" (i.e.,
> the reported block) is a reused object provided by BlockListAsLongs#iterator.
> Later this object is reused by directly changing its ID/GS. Thus
> {{addStoredBlock}} can get wrong (reportedBlock, stored-BlockInfo) mapping.
> For EC the reported block is used to calculate the internal block index. Thus
> the bug can completely corrupt the EC block group internal states.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
