[
https://issues.apache.org/jira/browse/HDFS-9918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15219241#comment-15219241
]
Walter Su commented on HDFS-9918:
---------------------------------
The optimization works for {{BlockInfoStriped}}. A missing block occupies a
slot. Like
{noformat}
0, null, 2, 3, 4, 5, 6, 7, 8, 1, 0', 1', 7', 8'
{noformat}
In LocatedStripedBlock, the data is like
{noformat}
0, 2, 3, 4, 5, 6, 7, 8, 1, 0', 1', 7', 8'
{noformat}
That's why I don't see the point maintain the order (of the in-service ones).
Unless we change {{createLocatedBlock(..)}}. But optimizing
{{LocatedStripedBlock}} to save some network traffic seems trival.
> Erasure Coding: Sort located striped blocks based on decommissioned states
> --------------------------------------------------------------------------
>
> Key: HDFS-9918
> URL: https://issues.apache.org/jira/browse/HDFS-9918
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Rakesh R
> Assignee: Rakesh R
> Attachments: HDFS-9918-001.patch, HDFS-9918-002.patch,
> HDFS-9918-003.patch, HDFS-9918-004.patch, HDFS-9918-005.patch,
> HDFS-9918-006.patch, HDFS-9918-007.patch, HDFS-9918-008.patch
>
>
> This jira is a follow-on work of HDFS-8786, where we do decommissioning of
> datanodes having striped blocks.
> Now, after decommissioning it requires to change the ordering of the storage
> list so that the decommissioned datanodes should only be last node in list.
> For example, assume we have a block group with storage list:-
> d0, d1, d2, d3, d4, d5, d6, d7, d8, d9
> mapping to indices
> 0, 1, 2, 3, 4, 5, 6, 7, 8, 2
> Here the internal block b2 is duplicated, locating in d2 and d9. If d2 is a
> decommissioning node then should switch d2 and d9 in the storage list.
> Thanks [~jingzhao] for the
> [discussions|https://issues.apache.org/jira/browse/HDFS-8786?focusedCommentId=15180415&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15180415]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
