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.21.0, 0.20.2
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
Priority: Minor
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
