[HDFS-10858] FBR processing may generate incorrect reportedBlock-blockGroup mapping

• Type: Sub-task
• Status: Resolved
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 3.0.0-alpha1
• Fix Version/s: 3.0.0-alpha2
• Component/s: erasure-coding
• Target Version/s: 3.0.0-alpha2
• Hadoop Flags: Reviewed
• Assignee: Jing Zhao
• Reporter: Jing Zhao
• Created: 12/Sep/16 18:22
• Updated: 28/Nov/16 05:42
• Resolved: 12/Sep/16 23:42

Description

In BlockManager#reportDiffSorted:

    } 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));
    }

"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.

Issue Links

• is related to: HDFS-10775 Under-Replicated Blocks can not be recovered
• is related to: HDFS-10815 The state of the EC file is erroneously recognized when you restart the NameNode.