[ 
https://issues.apache.org/jira/browse/HDFS-16846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635902#comment-17635902
 ] 

ASF GitHub Bot commented on HDFS-16846:
---------------------------------------

lfxy commented on PR #5143:
URL: https://github.com/apache/hadoop/pull/5143#issuecomment-1320081540

   @tasanuma Yes, you are right,  when decommission DNs, both ec blocks and 
replication blocks are belong to replication tasks. 
   And in DatanodeDescriptor class, replication blocks and ec blocks are both 
in 'BlockQueue<BlockTargetPair> replicateBlocks'. I think if we want to 
distinguish ec blocks and replication blocks in replication tasks when 
decommissioning dns, we need to put ec blocks in another variable in 
DataNodeDescriptor class besides 'replicateBlocks', such as 
'BlockQueue<BlockTargetPair> ecReplicatedBlocks'. Do you agree me?




> EC: Only EC blocks should be effected by max-streams-hard-limit configuration
> -----------------------------------------------------------------------------
>
>                 Key: HDFS-16846
>                 URL: https://issues.apache.org/jira/browse/HDFS-16846
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: ec
>    Affects Versions: 3.4.0
>            Reporter: caozhiqiang
>            Assignee: caozhiqiang
>            Priority: Major
>              Labels: pull-request-available
>
> In [HDFS-16613|https://issues.apache.org/jira/browse/HDFS-16613], the 
> dfs.namenode.replication.max-streams-hard-limit configuration will only 
> affect decommissioning DataNode, but will not distinguish between replication 
> blocks and EC blocks. Even if DataNodes have only replication files, they 
> will always generate high network traffic. So this configuration should only 
> effect EC blocks.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to