[HDFS-11019] Inconsistent number of corrupt replicas if a corrupt replica is reported multiple times

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Duplicate
• Component/s: namenode

Environment

CDH5.7.2

• Assignee: Unassigned
• Reporter: Wei-Chiu Chuang
• Created: 15/Oct/16 20:44
• Updated: 02/Oct/19 17:15
• Resolved: 20/Oct/16 17:48

Description

While investigating a block corruption issue, I found the following warning message in the namenode log:

(a client reports a block replica is corrupt)
2016-10-12 10:07:37,166 INFO BlockStateChange: BLOCK NameSystem.addToCorruptReplicasMap: blk_1073803461 added as corrupt on 10.0.0.63:50010 by /10.0.0.62  because client machine reported it
2016-10-12 10:07:37,166 INFO BlockStateChange: BLOCK* invalidateBlock: blk_1073803461_74513(stored=blk_1073803461_74553) on 10.0.0.63:50010
2016-10-12 10:07:37,166 INFO BlockStateChange: BLOCK* InvalidateBlocks: add blk_1073803461_74513 to 10.0.0.63:50010

(another client reports a block replica is corrupt)
2016-10-12 10:07:37,728 INFO BlockStateChange: BLOCK NameSystem.addToCorruptReplicasMap: blk_1073803461 added as corrupt on 10.0.0.63:50010 by /10.0.0.64  because client machine reported it
2016-10-12 10:07:37,728 INFO BlockStateChange: BLOCK* invalidateBlock: blk_1073803461_74513(stored=blk_1073803461_74553) on 10.0.0.63:50010

(ReplicationMonitor thread kicks in to invalidate the replica and add a new one)
2016-10-12 10:07:37,888 INFO BlockStateChange: BLOCK* ask 10.0.0.56:50010 to replicate blk_1073803461_74553 to datanode(s) 10.0.0.63:50010
2016-10-12 10:07:37,888 INFO BlockStateChange: BLOCK* BlockManager: ask 10.0.0.63:50010 to delete [blk_1073803461_74513]

(the two maps are inconsistent)
2016-10-12 10:08:00,335 WARN org.apache.hadoop.hdfs.server.blockmanagement.BlockManager: Inconsistent number of corrupt replicas for blk_1073803461_74553 blockMap has 0 but corrupt replicas map has 1

It seems that when a corrupt block replica is reported twice, blockMap corrupt and corrupt replica map becomes inconsistent.

Looking at the log, I suspect the bug is in BlockManager#removeStoredBlock. When a corrupt replica is reported, BlockManager removes the block from blocksMap. If the block is already removed (that is, the corrupt replica is reported twice), return; Otherwise (that is, the corrupt replica is reported the first time), remove the block from corruptReplicasMap (The block is added into corruptReplicasMap in BlockerManager#markBlockAsCorrupt) Therefore, after the second corruption report, the corrupt replica is removed from blocksMap, but the one in corruptReplicasMap is not removed.

I can’t tell what’s the impact that they are inconsistent. But I feel it's a good idea to fix it.