[ https://issues.apache.org/jira/browse/HDFS-14834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925447#comment-16925447 ]
janick.wu commented on HDFS-14834: ---------------------------------- [~ayushtkn] yes, it can fix this bug, thxs for your attention > in some particular situation, datanode will always in DECOMMISSION_INPROGRESS > state > ----------------------------------------------------------------------------------- > > Key: HDFS-14834 > URL: https://issues.apache.org/jira/browse/HDFS-14834 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs > Affects Versions: 3.1.2 > Environment: Policy:RS-6-3-1024K > Version:3.1.2 > Reporter: janick.wu > Priority: Major > > The file's block index is [0,1,2,3,4,5,6,7,8]. I decommission index [3] and > increase the index 5 datanode's pendingReplicationWithoutTargets. > After reconstruction of index 5, the block status is: > ||index||isDecommissionInProgress||state|| > |0| false|LIVE| > |1| false|LIVE| > |2| false|LIVE| > |3| true|DECOMMISSIONING| > |4| false|LIVE| > |5| false|LIVE| > |6| false|LIVE| > |7| false|LIVE| > |8| false|LIVE| > |5| false|LIVE| > > In DatanodeAdminManager.Monitor thread, blockManager.countNodes(block) > caculate the live bitset is \{0, 1, 2, 4, 5, 6, 7, 8}, liveReplicas: 8, > redundant:1 > It's a low redundancy block, put it into queue and wait for schedule. > In BlockManager.RedundancyMonitor thread, live bitset is \{0, 1, 2, 3, 4, 6, > 7, 8} , liveReplicas:9, redundant :0 > The block waitting for replication will remove from queue, rbecause the > liveReplicas satisfies the expected redundancy > And this situation would lead to index[3]'s datanode allways in > DECOMMISSION_INPROGRESS state > -- This message was sent by Atlassian Jira (v8.3.2#803003) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org