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

Zhe Zhang commented on HDFS-7652:
---------------------------------

[~jingzhao] Your implementation of {{getStoredBlock}} in 003 patch is correct 
-- it handles conflicts with legacy (randomly generated) block IDs. I just 
updated the patch.

> Process block reports for erasure coded blocks
> ----------------------------------------------
>
>                 Key: HDFS-7652
>                 URL: https://issues.apache.org/jira/browse/HDFS-7652
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>            Reporter: Zhe Zhang
>            Assignee: Zhe Zhang
>         Attachments: HDFS-7652.001.patch, HDFS-7652.002.patch, 
> HDFS-7652.003.patch, HDFS-7652.004.patch, HDFS-7652.005.patch
>
>
> HDFS-7339 adds support in NameNode for persisting block groups. For memory 
> efficiency, erasure coded blocks under the striping layout are not stored in 
> {{BlockManager#blocksMap}}. Instead, entire block groups are stored in 
> {{BlockGroupManager#blockGroups}}. When a block report arrives from the 
> DataNode, it should be processed under the block group that it belongs to. 
> The following naming protocol is used to calculate the group of a given block:
> {code}
>  * HDFS-EC introduces a hierarchical protocol to name blocks and groups:
>  * Contiguous: {reserved block IDs | flag | block ID}
>  * Striped: {reserved block IDs | flag | block group ID | index in group}
>  *
>  * Following n bits of reserved block IDs, The (n+1)th bit in an ID
>  * distinguishes contiguous (0) and striped (1) blocks. For a striped block,
>  * bits (n+2) to (64-m) represent the ID of its block group, while the last m
>  * bits represent its index of the group. The value m is determined by the
>  * maximum number of blocks in a group (MAX_BLOCKS_IN_GROUP).
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to