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

Zhe Zhang commented on HDFS-7285:
---------------------------------

{quote}
Thanks for your great job about making erasure code native in HDFS. 
I am working on proactive data protection in HDFS by incorporating hard drive 
failure detection method based on collected SMART attributes into HDFS kernel 
and scheduling disk warning process in advance and want to have erasure code 
native supported by HDFS kernel instead of HDFS-RAID.
I have some questions below, but I don't know how to consult them , so I just 
list my questions here and hope it won't bother you so much.
1, I am wonderring whether and where i can download the project source code you 
are working on.
2, When this project will be accomplished, will it take a long time ?
3, Whether guys like me can join your group?
{quote}
Copying [comments | 
https://issues.apache.org/jira/browse/HDFS-8193?focusedCommentId=14539778&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14539778]
 from [~lpstudy] over here and please find my answers below:
# Erasure coding has been developed under the HDFS-7285 branch and the code can 
be accessed on github: https://github.com/apache/hadoop/tree/HDFS-7285
# We haven't explicitly discussed the target Hadoop release of the erasure 
coding feature. The plan will be discussed here.
# Sure! Contributions are always very welcome. Please feel free to file JIRAs 
on issues you see or take existing ones after checking with original assignee.

> 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: ECAnalyzer.py, ECParser.py, HDFS-7285-initial-PoC.patch, 
> HDFSErasureCodingDesign-20141028.pdf, HDFSErasureCodingDesign-20141217.pdf, 
> HDFSErasureCodingDesign-20150204.pdf, HDFSErasureCodingDesign-20150206.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)

Reply via email to