在NameNode的${dfs.namenode.name.dir}/current目錄下，有這樣幾個文件：
在數據庫系統中，log是用於記錄寫操作的日誌的，並使用該Log進行備份、恢復數據等工作。有關寫的操作的記錄的，目前見過了兩種：關係型數據庫的log，HBase的WALs等等都是這樣的寫操作的日誌。
HDFS也採用了類似的機制。在HDFS中，會將第一次的文件操作，看作一個事務。譬如說一個文件的創建、文件內容追加、文件移動等等寫操作。從這個角度來看呢，fsp_w_picpath文件就相當於HDFS 的元數據的數據庫文件了，而edit log就相當於是操作日誌文件了。
Fsp_w_picpath：
每個fsp_w_picpath文件都會包括整個文件系統中所有的目錄和文件inodes信息。每個inode是HDFS內部的一個代表文件、或者目錄的元數據，如果inode代表一個文件，它包括：文件的備份級別、修改時間、訪問時間、訪問權限、block的size、所有blocks的構成等信息。如果inode代表一個目錄，它包括：修改時間、權限、其它相關元數據等。
Edit log：
它在邏輯上，是一個實例（也就是說可以理解爲一個對象），實際上是由多個文件組成的。每個文件都被稱爲一個segment，並以 edits_作爲前綴，文件名後面的是事務id。
譬如上面的：edits_0000000000011403382-0000000000011403408 就代表該文件中放的是
事務Id爲0000000000011403382到0000000000011403408之間的那些事務的信息。當客戶端完成了一個寫操作，並收到namenode的success的響應碼時，Namenode纔會將該事務信息寫到editlog文件中。
爲什麼將事務信息處理後不直接寫到fsp_w_picpath中？
如果這樣做的話，也就是每個write操作完畢時，都去更新fsp_w_picpath文件，在一個大的文件系統中，文件就會變得很大，上GB都是有可能的，那麼將是一個緩慢的過程。
先寫到edit log中，怎麼合併到fsp_w_picpath中呢？
解決方案是啓動一個Secondary namenode。它的存在就是在內存中生成Primary NameNode的fsp_w_picpath文件。它的處理過程是這樣的：
1、Secondary 告訴Primary去滾動它的in-progress edits文件，這樣新來的write操作就會放到一個新的edit 文件中。同時Primary也會更新seen_txid文件。
2、Secondary 通過HTTP GET方式從Primary獲取到最新的fsp_w_picpath和edits文件
3、Secondary 將fsp_w_picpath加載到內存中，並從edits文件中取出每一次事務，應用到fsp_w_picpath上，如此就產生了一個合併的新的fsp_w_picpath文件。
4、Secondary將這個新合併的fsp_w_picpath文件通過HTTP PUT發到Primary，Primary把它保存到臨時.ckpt文件中。
5、Primary再把臨時文件重命名，並使它可用。
同時，這也是爲啥Secondary需要與Primary類似的內存配置，並且需要部署在一個單獨的機器。
NameNode爲什麼不自己做合併，而是由Seconary NameNode來做呢？
NameNode不是不自己做，只是在啓動時做。
首先，所有的寫操作都會經過NameNode來處理，所以fap_w_picpath的內容，在NameNode的內存裏，
肯定是有同樣的一份。所以在運行期間，不需要通過合併來保證與內存一致。
其次，NameNode只是在啓動時才進行合併操作。
也正由於這兩點原因，所以需要由Secondary NameNode來完成了。不然NameNode運行了很長時間，比如累積了大量的editlog，而fsp_w_picpath又是NameNode啓動後的那一次合併後的狀態。那麼NameNode重啓後必然要進行長時間的合併操作。