在hadoopor論壇裏看到這樣的問題，這裏做個回答。
我有一個疑問，在namenode的內存中記錄了fsimsage信息，
但是內存中的fsp_w_picpath元數據是在namemode啓動時去合併本地的
editlog和fsp_w_picpath得到的，這樣的話就存在以下問題：
1. 如果namenode一直不重新啓動的話
那麼如何保證內存中的fsp_w_picpath是最新的呢
2.在最新的hdfs版本中是否支持週期性的去合併本地editlog和fsp_w_picpath信息？
3.本地的fsp_w_picpath中的元數據是在什麼時候寫入的？
新建文件的時候會向editlog中記錄日誌
是在這個時候把元數據寫入到fsp_w_picpath中的嗎？
如果是，那麼editlog爲什麼還要和fsp_w_picpath進行合併？
因爲editlog中記錄的元數據，在fsp_w_picpath中都已經有了。
那位能幫忙解答下，不勝感激。
解答：
1：問題本身就有問題，fsp_w_picpath是存於硬盤的元數據檢查點，Hadoop不會對每個文件操作都寫出到fsp_w_picpath，這樣是很慢的，但是每個文件操作都會在提交後運行前先寫入edits編輯日誌，這樣在namenode出現故障後，就會將fsp_w_picpath和edits編輯日誌結合讀入內存，重建元數據信息。具體的檢查點和日誌滾動，可以參見數據庫的檢查點和Apache的日誌滾動技術。
2：上面也說過，參考數據庫的檢查點知識。爲了避免edits編輯日誌的無限制擴大，secondary namenode 就回按照時間閾值（比如1小時）或者按大小閾值（edits編輯日誌文件大小超過64M，這些參數都可以設置）“週期性”的讀取namenode中的edits和fsp_w_picpath重構fsp_w_picpath檢查點，同時在namenode中進行edits的滾動，來解決這個問題。
3：正確理解了namenode和secondary namenode的機制就明白了fsp_w_picpath是“週期性”的進行更新的。