Return-Path: X-Original-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 437CE10075 for ; Sun, 1 Feb 2015 07:39:35 +0000 (UTC) Received: (qmail 58327 invoked by uid 500); 1 Feb 2015 07:39:35 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 58261 invoked by uid 500); 1 Feb 2015 07:39:35 -0000 Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-issues@hadoop.apache.org Delivered-To: mailing list hdfs-issues@hadoop.apache.org Received: (qmail 58249 invoked by uid 99); 1 Feb 2015 07:39:35 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Feb 2015 07:39:35 +0000 Date: Sun, 1 Feb 2015 07:39:35 +0000 (UTC) From: "Yi Liu (JIRA)" To: hdfs-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (HDFS-7285) Erasure Coding Support inside HDFS MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HDFS-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14300105#comment-14300105 ] Yi Liu edited comment on HDFS-7285 at 2/1/15 7:38 AM: ------------------------------------------------------ {quote} Good catch. I need to update that design doc to match the 64KB default stripe cell size. BTW 1MB is the I/O buffer size (see parameters C and B on page 8 of the master design doc {quote} I think we need to allow dynamic stripe cell size depends on the file size. If we only use small fixed value, for example 64KB as the stripe cell size, then for large file, we need much more ec block groups to store the entire file than the number of blocks we need using replication way, even as implemented in HDFS-7339, we only store the first ec block of the ec block groups in NN, but the NN memory consumption is a big issue since there are too many ec block groups. was (Author: hitliuyi): {quote} Good catch. I need to update that design doc to match the 64KB default stripe cell size. BTW 1MB is the I/O buffer size (see parameters C and B on page 8 of the master design doc {quote} I think we need to allow dynamic stripe cell size depends on the file size. If we only use small fixed value, for example 64KB as the stripe cell size, then for large file, we need much more ec block groups to store the entire file than using replication way, even as implemented in HDFS-7339, we only store the first ec block of the ec block groups in NN, but the NN memory consumption is a big issue since there are too many ec block groups. > 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)