在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是“周期性”的进行更新的。