[
https://issues.apache.org/jira/browse/HDFS-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14366293#comment-14366293
]
Jing Zhao commented on HDFS-7285:
---------------------------------
Thanks for the comment, Zhe! Some comments inline:
bq. In the storage policy XAttr, always store the actual policy instead of the
desired one
As you mentioned in #4, this may finally lead to the requirement that every
file/block has to store its own "actual" storage policy. My main concern is
that doing this in file level will lead to much harder management.
Administrators have to check individual files to understand its storage scheme.
bq. Mover (or a similar tool) should keep track of a queue of desired changes
Considering Mover is just an external tool, if we use storage policy for EC
files, clients (including Mover) will still directly talk to NN to set storage
policy. And finally these desired changes still have to be handled/maintained
by NN (or even a separate HDFS internal service).
bq. Conversion between replication and EC is a very important use case; so we
do need to support changing EC policy on files and dirs
Agree. But different from HSM, where the migration only moves blocks across
datanodes and keeps file->block metadata unchanged, the conversion between
replication and EC will finally generate brand new blocks for the file.
Therefore, a much simpler and maybe cleaner way for conversion can be just
copying the files using the new scheme, deleting the old data after the copy ,
and renaming the new data using old names if necessary. This will not cause
inefficiency since anyway we need to write new data. Also this can be simply
adopted by a Mover like tool, and can avoid a lot of complexity when handling
changes on files during the conversion.
In general, currently I prefer an EC-Zone design:
# Conversion is supported through copy
# EC policy is annotated on root directory of the zone as its XAttr
# No rename or EC schema change is allowed
This is very similar with specifying the EC schema in the volume level (if we
later support volume).
> 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)
