在NameNode的${dfs.namenode.name.dir}/current目錄下，有這樣幾個文件：
在數(shù)據(jù)庫系統(tǒng)中，log是用于記錄寫操作的日志的，并使用該Log進(jìn)行備份、恢復(fù)數(shù)據(jù)等工作。有關(guān)寫的操作的記錄的，目前見過了兩種：關(guān)系型數(shù)據(jù)庫的log，HBase的WALs等等都是這樣的寫操作的日志。
HDFS也采用了類似的機(jī)制。在HDFS中，會將第一次的文件操作，看作一個事務(wù)。譬如說一個文件的創(chuàng)建、文件內(nèi)容追加、文件移動等等寫操作。從這個角度來看呢，fsimage文件就相當(dāng)于HDFS 的元數(shù)據(jù)的數(shù)據(jù)庫文件了，而edit log就相當(dāng)于是操作日志文件了。
Fsimage：
每個fsimage文件都會包括整個文件系統(tǒng)中所有的目錄和文件inodes信息。每個inode是HDFS內(nèi)部的一個代表文件、或者目錄的元數(shù)據(jù)，如果inode代表一個文件，它包括：文件的備份級別、修改時間、訪問時間、訪問權(quán)限、block的size、所有blocks的構(gòu)成等信息。如果inode代表一個目錄，它包括：修改時間、權(quán)限、其它相關(guān)元數(shù)據(jù)等。
Edit log：
它在邏輯上，是一個實例（也就是說可以理解為一個對象），實際上是由多個文件組成的。每個文件都被稱為一個segment，并以 edits_作為前綴，文件名后面的是事務(wù)id。
譬如上面的：edits_0000000000011403382-0000000000011403408 就代表該文件中放的是
事務(wù)Id為0000000000011403382到0000000000011403408之間的那些事務(wù)的信息。當(dāng)客戶端完成了一個寫操作，并收到namenode的success的響應(yīng)碼時，Namenode才會將該事務(wù)信息寫到editlog文件中。
為什么將事務(wù)信息處理后不直接寫到fsimage中？
如果這樣做的話，也就是每個write操作完畢時，都去更新fsimage文件，在一個大的文件系統(tǒng)中，文件就會變得很大，上GB都是有可能的，那么將是一個緩慢的過程。
先寫到edit log中，怎么合并到fsimage中呢？
解決方案是啟動一個Secondary namenode。它的存在就是在內(nèi)存中生成Primary NameNode的fsimage文件。它的處理過程是這樣的：
