[
https://issues.apache.org/jira/browse/HDFS-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14559096#comment-14559096
]
Walter Su commented on HDFS-8453:
---------------------------------
{code}
+ bg.getStartOffset(), bg.isCorrupt(), null);
{code}
The 00 patch assign all offsets of inner blocks with {{bg.getStartOffset()}}. I
think it will be enough to solve the problem.
{{refreshLocatedBlock}} is good to me. It can solve {{getBlockAt}}. But you
have to solve {{fetchBlockAt}} too.
bq. My current plan is to keep using bg.getStartOffset() + idxInBlockGroup *
cellSize as the start offset for data blocks. For parity blocks, use -1 *
(bg.getStartOffset() + idxInBlockGroup * cellSize).
If you gonna do that. You have to change
{{DFSStripedInputStream.refreshLocatedBlock()}} to deal with negative offsets.
So It won't seek to wrong block. Is it your plan in next patch? I'm +1 for this
idea.
> Erasure coding: properly assign start offset for internal blocks in a block
> group
> ---------------------------------------------------------------------------------
>
> Key: HDFS-8453
> URL: https://issues.apache.org/jira/browse/HDFS-8453
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Zhe Zhang
> Assignee: Zhe Zhang
> Attachments: HDFS-8453-HDFS-7285.00.patch
>
>
> {code}
> void actualGetFromOneDataNode(final DNAddrPair datanode,
> ...
> LocatedBlock block = getBlockAt(blockStartOffset);
> ...
> fetchBlockAt(block.getStartOffset());
> {code}
> The {{blockStartOffset}} here is from inner block. For parity blocks, the
> offset will overlap with the next block group, and we may end up with
> fetching wrong block. So we have to assign a meaningful start offset for
> internal blocks in a block group, especially for parity blocks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
