下面所有的內容是針對Hadoop 2.x版本進行說明的，Hadoop 1.x和這裏有點不一樣。
在第一次部署好Hadoop集羣的時候，我們需要在NameNode（NN）節點上格式化磁盤：
ubuntu@ubuntu hadoop-2.2.0]$ $HADOOP_HOME/bin/hdfs namenode -format
格式化完成之後，將會在$dfs.namenode.name.dir/current目錄下如下的文件結構
current/ |-- VERSION |-- edits_* |-- fsp_w_picpath_0000000000008547077 |-- fsp_w_picpath_0000000000008547077.md5 `-- seen_txid
其中的dfs.namenode.name.dir是在hdfs-site.xml文件中配置的，默認值如下：
name=dfs.namenode.name.dir
value=file://${hadoop.tmp.dir}/dfs/name其中的hadoop.tmp.dir是在core-site.xml中配置的，默認值如下:
name=hadoop.tmp.dir
value=/tmp/hadoop-${user.name}dfs.namenode.name.dir屬性可以配置多個目錄，如/data1/dfs/name,/data2/dfs/name, /data3/dfs/name,….。各個目錄存儲的文件結構和內容都完全一樣，相當於備份，這樣做的好處是當其中一個目錄損壞了，也不會影響到 Hadoop的元數據，特別是當其中一個目錄是NFS（網絡文件系統Network File System，NFS）之上，即使你這臺機器損壞了，元數據也得到保存。
下面對$dfs.namenode.name.dir/current/目錄下的文件進行解釋。
1、VERSION文件是Java屬性文件，內容大致如下：
#Fri Nov 15 19:47:46 CST 2013 namespaceID=934548976 clusterID=CID-cdff7d73-93cd-4783-9399-0a22e6dce196 cTime=0 storageType=NAME_NODE blockpoolID=BP-893790215-192.168.24.72-1383809616115 layoutVersion=-47
其中
（1）、namespaceID是文件系統的唯一標識符，在文件系統首次格式化之後生成的；
（2）、storageType說明這個文件存儲的是什麼進程的數據結構信息（如果是DataNode，storageType=DATA_NODE）；
（3）、cTime表示NameNode存儲時間的創建時間，由於我的NameNode沒有更新過，所以這裏的記錄值爲0，以後對NameNode升級之後，cTime將會記錄更新時間戳；
（4）、layoutVersion表示HDFS永久性數據結構的版本信息， 只要數據結構變更，版本號也要遞減，此時的HDFS也需要升級，否則磁盤仍舊是使用舊版本的數據結構，這會導致新版本的NameNode無法使用；
（5）、clusterID是系統生成或手動指定的集羣ID，在-clusterid選項中可以使用它；如下說明
a、使用如下命令格式化一個Namenode：
$HADOOP_HOME/bin/hdfs namenode -format [-clusterId ]
選擇一個唯一的cluster_id，並且這個cluster_id不能與環境中其他集羣有衝突。如果沒有提供cluster_id，則會自動生成一個唯一的ClusterID。
b、使用如下命令格式化其他Namenode：
$HADOOP_HOME/bin/hdfs namenode -format -clusterId
c、升級集羣至最新版本。在升級過程中需要提供一個ClusterID，例如：
$HADOOP_PREFIX_HOME/bin/hdfs start namenode --config $HADOOP_CONF_DIR -upgrade -clusterId
如果沒有提供ClusterID，則會自動生成一個ClusterID。
（6）、blockpoolID：是針對每一個Namespace所對應的blockpool的ID，上面的這個BP- 893790215-192.168.24.72-1383809616115就是在我的ns1的namespace下的存儲塊池的ID，這個ID包括了 其對應的NameNode節點的ip地址。
2、$dfs.namenode.name.dir/current/seen_txid非常重要，是存放transactionId的文 件，format之後是0，它代表的是namenode裏面的edits_*文件的尾數，namenode重啓的時候，會按照seen_txid的數字， 循序從頭跑edits_0000001~到seen_txid的數字。所以當你的hdfs發生異常重啓的時候，一定要比對seen_txid內的數字是不 是你edits最後的尾數，不然會發生建置namenode時metaData的資料有缺少，導致誤刪Datanode上多餘Block的資訊。
3、$dfs.namenode.name.dir/current目錄下在format的同時也會生成fsp_w_picpath和edits文件，及其 對應的md5校驗文件。fsp_w_picpath和edits是Hadoop元數據相關的重要文件，我打算在下一篇文章中fsp_w_picpath和edits存儲的內容和他 們之間的關係進行說明，請關注本博客。