[
https://issues.apache.org/jira/browse/HDFS-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14280720#comment-14280720
]
Zhe Zhang commented on HDFS-7285:
---------------------------------
[~szetszwo] Thank you for reviewing the design doc; great questions!
bq. Is a BlockGroup only used by one file, i.e. it cannot be shared by servel
files?
Each BlockGroup is used by only one file. In general, bundling multiple files
in a single erasure coding stripe/group complicates file deletions.
bq. Suppose the answer to the above question is yes. Then, how to encode small
files?
That's the benefit of striping: when divided into small units (64KB by default)
and striped to multiple servers, even small files can be encoded. The fsimage
analysis report quantifies the difference in space saving between striping and
the traditional contiguous data layouts.
bq. "HDFS truncate" is now committed. We should revisit it. (EC with truncation
is still a non-goal in the design doc.)
Good point. I will update the design doc to address this. We can either
disallow truncate for encoded files, or convert the file (or at least the last
block) into replication before truncating.
bq. "Due to the complexity we will not support hflush or hsync for EC files at
this phase." Then what will happen if users call hflush/hsync?
Similar as above, we can either return an error telling the user hflush/hsync
is not supported on the target file, or convert the file first (which sounds
like too slow for frequent flush/sync operations). An ongoing optimization is
to leverage the _incremental encoding_ feature from Intel's Storage
Acceleration Library (ISAL) to flush parity data from partial stripe, and
updating the parity data when more data is available.
bq. HDFS upgrade is not covered in the doc. More specifically, if there are
existing blocks using the block id's reserved for BlockGroup, how to upgrade
the cluster? And how to rollback?
This is a really good catch. IIUC
{{SequentialBlockIdGenerator#LAST_RESERVED_BLOCK_ID}} is for this purpose? We
can just divided the _unreserved_ ID space into regular blocks and BlockGroups.
The latest patch under HDFS-7339 implements this logic
({{SequentialBlockIdGenerator}} and {{SequentialBlockGroupIdGenerator}}.
> 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,
> HDFSErasureCodingDesign-20141028.pdf, HDFSErasureCodingDesign-20141217.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)
