[
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
