[
https://issues.apache.org/jira/browse/HDFS-7912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14355445#comment-14355445
]
Zhe Zhang commented on HDFS-7912:
---------------------------------
bq. In general I think to track the whole BlockInfoStriped for recovery may be
easier than to track individual data/parity blocks inside, because in this way
we can wrap the internal recovery and priority logic inside of striped block.
Agreed on the rationale. But I guess {{BlockManager}} and
{{ReplicationMonitor}} never see individual data/parity blocks anyway? They are
never stored in the blocksMap.
Another thought: if {{UnderReplicatedBlocks}} tracks {{BlockInfo}}, we can
actually wrap more risk-calculating logic in the {{UnderReplicatedBlocks}}
class. Right now multiple places call {{UnderReplicatedBlocks#add}} with some
duplicate logic.
bq. But I have not checked the HDFS-7369 patch yet. I will read the patch later
today.
Thanks in advance. I'll post a rev soon today. Per discussion above the new rev
will focus on {{ReplicationMonitor}} so it's oblivious to the ongoing work here.
> Erasure Coding: track BlockInfo instead of Block in UnderReplicatedBlocks and
> PendingReplicationBlocks
> ------------------------------------------------------------------------------------------------------
>
> Key: HDFS-7912
> URL: https://issues.apache.org/jira/browse/HDFS-7912
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Jing Zhao
> Assignee: Jing Zhao
> Attachments: HDFS-7912.000.patch
>
>
> Now with striped blocks and the design that uses a single BlockInfoStriped
> object to track all the corresponding blocks, we need to clearly distinguish
> the type Block and BlockInfo in BlockManager. Specifically, data structures
> like {{UnderReplicatedBlocks}} and {{PendingReplicationBlocks}} should track
> BlockInfo instead of Block in order to support striped block recovery.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
