[
https://issues.apache.org/jira/browse/HDFS-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529400#comment-14529400
]
Tsz Wo Nicholas Sze commented on HDFS-7672:
-------------------------------------------
2. I also found it when running unit tests. Fixed it.
3. No, the current stream may become failed in the first if.
Structural:
1. I do have a separated JIRA HDFS-8288. Do you want to commit it first?
2. This was from HDFS-7889. We do not need to call super.locateFollowingBlock
in the first time since we already have the LocatedBlock.
3. I don't understand this question. Which line in the code?
4 & 5. The keep-writing method works very well in replication in many years.
The variable-length block method is new. So we must support keep-writing
method and may support the variable-length block method as an option.
6 & 7. I plan to add more tests later. Let me also think about how to make it
faster later.
Thanks a lot, Zhe.
> Erasure Coding: handle write failure for stripping coding blocks
> ----------------------------------------------------------------
>
> Key: HDFS-7672
> URL: https://issues.apache.org/jira/browse/HDFS-7672
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client
> Reporter: Tsz Wo Nicholas Sze
> Assignee: Tsz Wo Nicholas Sze
> Attachments: h7672_20150504.patch, h7672_20150504b.patch,
> h7672_20150504c.patch, h7672_20150505.patch
>
>
> In *stripping* case, for (6, 3)-Reed-Solomon, a client writes to 6 data
> blocks and 3 parity blocks concurrently. We need to handle datanode or
> network failures when writing a EC BlockGroup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
