Return-Path: Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: (qmail 99910 invoked from network); 20 Oct 2010 14:50:50 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 20 Oct 2010 14:50:50 -0000 Received: (qmail 24335 invoked by uid 500); 20 Oct 2010 14:50:50 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 24298 invoked by uid 500); 20 Oct 2010 14:50:49 -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 24290 invoked by uid 99); 20 Oct 2010 14:50:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Oct 2010 14:50:49 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Oct 2010 14:50:48 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o9KEoSXJ026220 for ; Wed, 20 Oct 2010 14:50:28 GMT Message-ID: <25619104.10031287586228262.JavaMail.jira@thor> Date: Wed, 20 Oct 2010 10:50:28 -0400 (EDT) From: "Aaron T. Myers (JIRA)" To: hdfs-issues@hadoop.apache.org Subject: [jira] Commented: (HDFS-1435) Provide an option to store fsimage compressed In-Reply-To: <7720269.489351285891053519.JavaMail.jira@thor> 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-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922987#action_12922987 ] Aaron T. Myers commented on HDFS-1435: -------------------------------------- Thanks for the clarification, Hairong. Konstantin commented in the original OIV JIRA (HADOOP-5467) that it would be nice if we eliminated the code duplication stemming from effectively having two distinct FS image loaders. Had we done that, you wouldn't have needed to remember to make this change in another place. This work probably shouldn't be done as part of this JIRA, this problem that you hit just reminded me of that. I've filed HDFS-1465 to address this problem. > Provide an option to store fsimage compressed > --------------------------------------------- > > Key: HDFS-1435 > URL: https://issues.apache.org/jira/browse/HDFS-1435 > Project: Hadoop HDFS > Issue Type: Improvement > Components: name-node > Affects Versions: 0.22.0 > Reporter: Hairong Kuang > Assignee: Hairong Kuang > Fix For: 0.22.0 > > Attachments: checkpoint-limitandcompress.patch, trunkImageCompress.patch, trunkImageCompress1.patch, trunkImageCompress2.patch, trunkImageCompress3.patch > > > Our HDFS has fsimage as big as 20G bytes. It consumes a lot of network bandwidth when secondary NN uploads a new fsimage to primary NN. > If we could store fsimage compressed, the problem could be greatly alleviated. > I plan to provide a new configuration hdfs.image.compressed with a default value of false. If it is set to be true, fsimage is stored as compressed. > The fsimage will have a new layout with a new field "compressed" in its header, indicating if the namespace is stored compressed or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.