Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Thu, 24 Feb 2011 20:10:38 +0000 (UTC)
From: "Tsz Wo (Nicholas), SZE (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: 
 <239929193.14281.1298578238657.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1743103666.4017.1297094071009.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Updated: (HDFS-1612) HDFS Design Documentation is outdated
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HDFS-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tsz Wo (Nicholas), SZE updated HDFS-1612:
-----------------------------------------

       Resolution: Fixed
    Fix Version/s: 0.23.0
                   0.22.0
                   0.21.1
           Status: Resolved  (was: Patch Available)

I have committed this.  Thanks, Joe!

(It would be great if you could also fix HDFS-1388.)

> HDFS Design Documentation is outdated
> -------------------------------------
>
>                 Key: HDFS-1612
>                 URL: https://issues.apache.org/jira/browse/HDFS-1612
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: documentation
>    Affects Versions: 0.20.2, 0.21.0
>         Environment: http://hadoop.apache.org/hdfs/docs/current/hdfs_design.html#The+Persistence+of+File+System+Metadata
> http://hadoop.apache.org/common/docs/r0.20.2/hdfs_design.html#The+Persistence+of+File+System+Metadata
>            Reporter: Joe Crobak
>            Assignee: Joe Crobak
>            Priority: Minor
>             Fix For: 0.21.1, 0.22.0, 0.23.0
>
>         Attachments: HDFS-1612.patch
>
>
> I was trying to discover details about the Secondary NameNode, and came across the description below in the HDFS design doc.
> {quote}
> The NameNode keeps an image of the entire file system namespace and file Blockmap in memory. This key metadata item is designed to be compact, such that a NameNode with 4 GB of RAM is plenty to support a huge number of files and directories. When the NameNode starts up, it reads the FsImage and EditLog from disk, applies all the transactions from the EditLog to the in-memory representation of the FsImage, and flushes out this new version into a new FsImage on disk. It can then truncate the old EditLog because its transactions have been applied to the persistent FsImage. This process is called a checkpoint. *In the current implementation, a checkpoint only occurs when the NameNode starts up. Work is in progress to support periodic checkpointing in the near future.*
> {quote}
> (emphasis mine).
> Note that this directly conflicts with information in the hdfs user guide, http://hadoop.apache.org/common/docs/r0.20.2/hdfs_user_guide.html#Secondary+NameNode
> and http://hadoop.apache.org/hdfs/docs/current/hdfs_user_guide.html#Checkpoint+Node
> I haven't done a thorough audit of that doc-- I only noticed the above inaccuracy.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira