[ https://issues.apache.org/jira/browse/HDFS-10453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15306312#comment-15306312 ]
He Xiaoqiao commented on HDFS-10453: ------------------------------------ hi [~vinayrpet], thanks for your comments. Actually this case occurs at Step 2 in {{BlockManager#computeReconstructionWorkForBlocks()}} which is not with global-lock held as you metioned. bq. 2. For blocks in work list, targets will be chosen. {{rw.chooseTargets}} will stuck for long time in the following scenarios: 1. *Blocks* are chosen to be reconstructed at {{neededReconstruction#chooseLowRedundancyBlocks(blocksToProcess)}} with global-lock held; 2. BlockReconstructionWork list {{reconWork}} will be created with the *blocks* which are exactly present at that time in {{scheduleReplication()}} also with global-lock. After creating list, lock is released. 3. Deletion happens at {{BlockManager#removeBlock(BlockInfo block)}} with global lock held. it is a critical parts of this case, {code} public void removeBlock(BlockInfo block) { assert namesystem.hasWriteLock(); // No need to ACK blocks that are being removed entirely // from the namespace, since the removal of the associated // file already removes them from the block map below. block.setNumBytes(BlockCommand.NO_ACK); addToInvalidates(block); removeBlockFromMap(block); // Remove the block from pendingReconstruction and neededReconstruction pendingReconstruction.remove(block); neededReconstruction.remove(block, LowRedundancyBlocks.LEVEL); if (postponedMisreplicatedBlocks.remove(block)) { postponedMisreplicatedBlocksCount.decrementAndGet(); } } {code} After {{removeBlock(BlockInfo block)}} *numbytes* of the block is set to BlockCommand.NO_ACK (=Long.MAX_VALUE), block is delete from {{neededReconstruction}},{{pendingReconstruction}} and {{blocksMap}}, but it is still referenced by {{reconWork}} which is local variable of {{BlockManager #computeReconstructionWorkForBlocks}}. 4. Choose target for each block in {{reconWork}}, but no Node could be selected after *traverse whole cluster* at this moment since numbytes of this block is Long.MAX_VALUE. if there are multiple blocks as depict above in a large cluster, Step 2 as flow below of {{BlockManager#computeReconstructionWorkForBlocks()}} will cost long time. it could be above *10 min* in our online cluster. {code} // Step 2: choose target nodes for each reconstruction task final Set<Node> excludedNodes = new HashSet<>(); for(BlockReconstructionWork rw : reconWork){ // Exclude all of the containing nodes from being targets. // This list includes decommissioning or corrupt nodes. excludedNodes.clear(); for (DatanodeDescriptor dn : rw.getContainingNodes()) { excludedNodes.add(dn); } // choose replication targets: NOT HOLDING THE GLOBAL LOCK // It is costly to extract the filename for which chooseTargets is called, // so for now we pass in the block collection itself. final BlockPlacementPolicy placementPolicy = placementPolicies.getPolicy(rw.getBlock().isStriped()); rw.chooseTargets(placementPolicy, storagePolicySuite, excludedNodes); } {code} 5. The rest processing as usually. FYI. > ReplicationMonitor thread could stuck for long time due to the race between > replication and delete of same file in a large cluster. > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: HDFS-10453 > URL: https://issues.apache.org/jira/browse/HDFS-10453 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode > Affects Versions: 2.4.1, 2.7.1 > Reporter: He Xiaoqiao > Attachments: HDFS-10453-branch-2.001.patch, > HDFS-10453-branch-2.003.patch, HDFS-10453.001.patch > > > ReplicationMonitor thread could stuck for long time and loss data with little > probability. Consider the typical scenarioļ¼ > (1) create and close a file with the default replicas(3); > (2) increase replication (to 10) of the file. > (3) delete the file while ReplicationMonitor is scheduling blocks belong to > that file for replications. > if ReplicationMonitor stuck reappeared, NameNode will print log as: > {code:xml} > 2016-04-19 10:20:48,083 WARN > org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy: Failed to > place enough replicas, still in need of 7 to reach 10 > (unavailableStorages=[], storagePolicy=BlockStoragePolicy{HOT:7, > storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}, > newBlock=false) For more information, please enable DEBUG log level on > org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy > ...... > 2016-04-19 10:21:17,184 WARN > org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy: Failed to > place enough replicas, still in need of 7 to reach 10 > (unavailableStorages=[DISK], storagePolicy=BlockStoragePolicy{HOT:7, > storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}, > newBlock=false) For more information, please enable DEBUG log level on > org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy > 2016-04-19 10:21:17,184 WARN > org.apache.hadoop.hdfs.protocol.BlockStoragePolicy: Failed to place enough > replicas: expected size is 7 but only 0 storage types can be selected > (replication=10, selected=[], unavailable=[DISK, ARCHIVE], removed=[DISK, > DISK, DISK, DISK, DISK, DISK, DISK], policy=BlockStoragePolicy{HOT:7, > storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}) > 2016-04-19 10:21:17,184 WARN > org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy: Failed to > place enough replicas, still in need of 7 to reach 10 > (unavailableStorages=[DISK, ARCHIVE], storagePolicy=BlockStoragePolicy{HOT:7, > storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}, > newBlock=false) All required storage types are unavailable: > unavailableStorages=[DISK, ARCHIVE], storagePolicy=BlockStoragePolicy{HOT:7, > storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]} > {code} > This is because 2 threads (#NameNodeRpcServer and #ReplicationMonitor) > process same block at the same moment. > (1) ReplicationMonitor#computeReplicationWorkForBlocks get blocks to > replicate and leave the global lock. > (2) FSNamesystem#delete invoked to delete blocks then clear the reference in > blocksmap, needReplications, etc. the block's NumBytes will set > NO_ACK(Long.MAX_VALUE) which is used to indicate that the block deletion does > not need explicit ACK from the node. > (3) ReplicationMonitor#computeReplicationWorkForBlocks continue to > chooseTargets for the same blocks and no node will be selected after traverse > whole cluster because no node choice satisfy the goodness criteria > (remaining spaces achieve required size Long.MAX_VALUE). > During of stage#3 ReplicationMonitor stuck for long time, especial in a large > cluster. invalidateBlocks & neededReplications continues to grow and no > consumes. it will loss data at the worst. > This can mostly be avoided by skip chooseTarget for BlockCommand.NO_ACK block > and remove it from neededReplications. -- 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