[
https://issues.apache.org/jira/browse/HDFS-8481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14564971#comment-14564971
]
Kai Zheng commented on HDFS-8481:
---------------------------------
Thanks Walter for the good ideas and Zhe for the update!
1. How about having {{RawDecoder decoder}} instead, in all places. Later we
would easily change to use other decoder.
{code}
+ private final RSRawDecoder rsRawDecoder;
{code}
2. I guess only when data blocks are erased it will run into here to decode. 1)
Should we count MISSING count and avoid too many blocks erased exception? 2) Do
we need the {{else}} block? 3) Note the code format minor.
{code}
+ } else if (chunk.state == StripingChunk.MISSING){
+ decodeInputs[i] = null;
+ } else {
+ decodeInputs[i] = null;
{code}
3. Around or in {{decodeAndFillBuffer}}, is it doable to use the source buffers
as input buffers and destination buffers as the output buffers directly to
avoid data copy?
4. I agree with Walter's concern, we would try to reuse related buffers or
structures around and across the decode calling. For that, we might need to
move them to and prepare them in the main class ({{DFSStripedInputStream}})
along with the decoder, or have a high level construct like
{{StrippedDecoder}}. As it's non-trivial, I agree we can do this separately,
but maybe in HDFS-7285?
> Erasure coding: remove workarounds in client side stripped blocks recovering
> ----------------------------------------------------------------------------
>
> Key: HDFS-8481
> URL: https://issues.apache.org/jira/browse/HDFS-8481
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Zhe Zhang
> Assignee: Zhe Zhang
> Attachments: HDFS-8481-HDFS-7285.00.patch,
> HDFS-8481-HDFS-7285.01.patch, HDFS-8481-HDFS-7285.02.patch,
> HDFS-8481-HDFS-7285.03.patch
>
>
> After HADOOP-11847 and related fixes, we should be able to properly calculate
> decoded contents.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
