fsimage 存储的都是文件系统元数据信息（文件及目录结构，组成文件的块的信息，副本数量信息），是文件元数据信息的持久性检查点，当 namenode 重启后都需要载入 fsimage 进入内存，恢复到某一检查点，再执行检查点后的编辑日志（editlog），进行重建。 检查点之后的操作记录会保存到 editlog 中，注意 editlog 存储的是操作记录而并非元数据，当 fsimage 与 editlog 合并时，会先将 editlog 执行一遍，生成元数据信息再与 fsimage 合并，每次合并后的位置就称为检查点
fsImage 与 editlog 的合并过程
secondaryNameNode 周期性（五分钟）getEditLog 获取 editLog 的大小，当其达到合并的大小时通过 RollEditLog 方法进行合并，或者距离上次合并达到一定时间也会进行合并
NameNode 停止使用 EditLog 文件，并生成一个新的临时的 edit.new文件
Secondarynamenode 通过 namenode 内建的 http 服务器，以 get 的方式获取 editLog 与 fsImage 文件。get 方法中携带着 editlog 和 fsImage 的地址
Secondarynamenode 将 fsImage 载入内存，并逐一执行 editLog 中的操作
执行结束后，会向 nameNode 发送 http 请求，通知 namenode 合并已经结束，namenode 通过 http 获取 fsimage.chk 文件
namenode 更新 fsimage 文件中记录检查点的执行时间，并改名为 fsimage文件
edit.new 更名为 edit 文件
注：
由此可知 namenode 与 secondarynamenode 有着相似的内存需求，因为 secondarynamenode 也会将 fsimage 载入内存，因此 secondarynamenode 需要运行在一台专用机器上
检查点的创建触发条件受两个配置参数控制：
secondarynamenode 每隔一个小时创建一个检查点
当 editlog 大小达到 64M 时，即使没达到一个小时也会创建一个检查点
3- SecondaryNameNode 在为 namenode 创建检查点的同时也会保留一份检查点的数据，在 tmp/dfs/namesecondary 的 current 目录下，该 current 目录与 namenode 下的 current 目录结构相同，便于使用 secondarynamenode 进行故障恢复，故障恢复有两种方法
将相关目录复制到新 namenode 中
启动 namenode 守护进程，将 secondarynamenode 作为 namenode（这种方法不知道操作方法）