[
https://issues.apache.org/jira/browse/HDFS-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhe Zhang updated HDFS-7285:
----------------------------
Attachment: Consolidated-20150707.patch
I finished a complete pass of the patch (both {{main}} and {{test}} codes) and
pushed to my github [repo |
https://github.com/zhe-thoughts/hadoop/tree/HDFS-EC-Merge]. Also uploading the
consolidated patch (renaming it again and hoping Jenkins applies it against
trunk instead of our branch).
I made some minor adjustments to the list of sub patches:
{code}
1. HADOOP-COMMON side support for codec calculations
2. Support Erasure Coding Zones.
3. Extend BlockInfo to handle striped block groups.
4. Allocate and manage striped blocks in NameNode blockmanagement module.
5. BlockPlacementPolicies for erasure coding
6. Create LocatedStripedBlock abstraction to represent striped block groups.
7. Distribute recovery work for striped blocks to DataNode.
8. Add striped block support in INodeFile.
9. Client side support
10. Datanode support
11. Change fsck to support EC files
12. Support striped block groups in fsimage and edit logs
13. Balancer and mover support for striped block groups
14. Additional unit tests for erasure coding
{code}
I also cherry-picked the 2 new patches from HDFS-7285 branch.
I created separate Jenkins builds for sub patches 1~4. Most tests passed. The
remaining handful of failures seem to be resulted from the patch splitting
(they pass in the final consolidated patch).
So *sub patches 1~4* are ready for reviews. Any comments and suggestions are
much appreciated. In particular, sub patch 3 has the new implementation of
{{BlockInfoStriped}} which has not been reviewed in the branch.
> 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, 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)
