date:20150814

[jira] [Updated] (HDFS-8838) Tolerate datanode failures in DFSStripedOutputStream when the data length is small

2015-08-14 Thread Walter Su (JIRA)


 [ 
https://issues.apache.org/jira/browse/HDFS-8838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Walter Su updated HDFS-8838:

Attachment: HDFS-8838-HDFS-7285-20150809-test.patch

A test patch HDFS-8838-HDFS-7285-20150809-test.patch to trigger Jenkins to test 
if HDFS-8896 works.

 Tolerate datanode failures in DFSStripedOutputStream when the data length is 
 small
 --

 Key: HDFS-8838
 URL: https://issues.apache.org/jira/browse/HDFS-8838
 Project: Hadoop HDFS
  Issue Type: Sub-task
  Components: hdfs-client
Reporter: Tsz Wo Nicholas Sze
Assignee: Tsz Wo Nicholas Sze
 Attachments: HDFS-8838-HDFS-7285-000.patch, 
 HDFS-8838-HDFS-7285-20150809-test.patch, HDFS-8838-HDFS-7285-20150809.patch, 
 h8838_20150729.patch, h8838_20150731-HDFS-7285.patch, h8838_20150731.log, 
 h8838_20150731.patch, h8838_20150804-HDFS-7285.patch, h8838_20150809.patch


 Currently, DFSStripedOutputStream cannot tolerate datanode failures when the 
 data length is small.  We fix the bugs here and add more tests.



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

[jira] [Commented] (HDFS-7285) Erasure Coding Support inside HDFS

2015-08-14 Thread Vinayakumar B (JIRA)

[
https://issues.apache.org/jira/browse/HDFS-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14696880#comment-14696880
]

Vinayakumar B commented on HDFS-7285:
-

I have tried to rebase current {{HDFS-7285}} branch against the current trunk
using {{git rebase trunk}}. It was not smooth as expected. Since I did not
wanted to push the rebase directly onto {{HDFS-7285}}, created one more branch
{{HDFS-7285-REBASE}}. This branch is just for reference purpose.

The advantage of this is, it retained all the commits along with message,date
and author details, even after resolving conflicts. I skipped one commit
purposefully HDFS-8787 to be in sync with trunk. it was just rename of files.
other than this, no other commits got squashed.

There were 192 commits to be rebased against trunk, including the intermediate
merge conflict resolved commits. Since I couldnt edit each and every commit to
resolve compilation errors after each commit, resolved remaining compilation
errors at the end, with one more commit.

If anyone wants to verify, please checkout the branch HDFS-7285-REBASE. and can
compare against the Consolidated patch.

Since this is only for trying to check the possibility of rebase, I am not
saying this should be considered as final branch.
If everyone feels good to go like this approach, I could do some more detailed
rebase next week, ( may be verify the compilation after each commit ? Not sure
whether its possible to stop for each commit rebase)

-Thanks

Erasure Coding Support inside HDFS
--

Key: HDFS-7285
URL: https://issues.apache.org/jira/browse/HDFS-7285
Project: Hadoop HDFS
Issue Type: New Feature
Reporter: Weihua Jiang
Assignee: Zhe Zhang
Attachments: Consolidated-20150707.patch,
Consolidated-20150806.patch, Consolidated-20150810.patch, ECAnalyzer.py,
ECParser.py, HDFS-7285-initial-PoC.patch,
HDFS-7285-merge-consolidated-01.patch,
HDFS-7285-merge-consolidated-trunk-01.patch,
HDFS-7285-merge-consolidated.trunk.03.patch,
HDFS-7285-merge-consolidated.trunk.04.patch,
HDFS-EC-Merge-PoC-20150624.patch, HDFS-EC-merge-consolidated-01.patch,
HDFS-bistriped.patch, HDFSErasureCodingDesign-20141028.pdf,
HDFSErasureCodingDesign-20141217.pdf, HDFSErasureCodingDesign-20150204.pdf,
HDFSErasureCodingDesign-20150206.pdf, HDFSErasureCodingPhaseITestPlan.pdf,
fsimage-analysis-20150105.pdf

Erasure Coding (EC) can greatly reduce the storage overhead without sacrifice
of data reliability, comparing to the existing HDFS 3-replica approach. For
example, if we use a 10+4 Reed Solomon coding, we can allow loss of 4 blocks,
with storage overhead only being 40%. This makes EC a quite attractive
alternative for big data storage, particularly for cold data.
Facebook had a related open source project called HDFS-RAID. It used to be
one of the contribute packages in HDFS but had been removed since Hadoop 2.0
for maintain reason. The drawbacks are: 1) it is on top of HDFS and depends
on MapReduce to do encoding and decoding tasks; 2) it can only be used for
cold files that are intended not to be appended anymore; 3) the pure Java EC
coding implementation is extremely slow in practical use. Due to these, it
might not be a good idea to just bring HDFS-RAID back.
We (Intel and Cloudera) are working on a design to build EC into HDFS that
gets rid of any external dependencies, makes it self-contained and
independently maintained. This design lays the EC feature on the storage type
support and considers compatible with existing HDFS features like caching,
snapshot, encryption, high availability and etc. This design will also
support different EC coding schemes, implementations and policies for
different deployment scenarios. By utilizing advanced libraries (e.g. Intel
ISA-L library), an implementation can greatly improve the performance of EC
encoding/decoding and makes the EC solution even more attractive. We will
post the design document soon.

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

1 2 >

1 - 100 of 134 matches

Mail list logo