[
https://issues.apache.org/jira/browse/HDFS-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14501477#comment-14501477
]
Walter Su commented on HDFS-8005:
---------------------------------
bq. The only concern is that the DN won't have the logic to prefer
DECOMMISSION_INPROGRESS nodes.
bq. HDFS-7742 has already removed this logic.
Replication blocks benefits little from DECOMMISSION_INPROGRESS preference( as
described in HDFS-7742). I think recovery from decommisioned EC block benefits
a lot from it.
Assume decommiss nodes containing lots of EC blocks, we have to re-compute all
the blocks. The computation consumes lots of CPU/Mem and network resources. We
had better just copy the blocks from that node to another. What do you think?
> Erasure Coding: simplify striped block recovery work computation and add tests
> ------------------------------------------------------------------------------
>
> Key: HDFS-8005
> URL: https://issues.apache.org/jira/browse/HDFS-8005
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Jing Zhao
> Assignee: Jing Zhao
> Fix For: HDFS-7285
>
> Attachments: HDFS-8005.000.patch, HDFS-8005.000.patch,
> HDFS-8005.001.patch
>
>
> HDFS-7369 adds the functionality to distribute recovery work of striped
> blocks to datanodes. There are still some pending issues:
> # In {{BlockManager#chooseSourceNode}}, a node is added into
> {{healthyIndices}} without checking if its block is live and healthy
> # The test {{TestRecoverStripedBlcoks#testMissingStripedBlock}} has not
> tested striped blocks because the file is created before setting the storage
> policy
> # In {{computeRecoveryWorkForBlocks}}, instead of using
> {{BlockCollection#isStriped}}, we'd better use {{BlockInfo#isStriped}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)