在说Fsimage的更新操作之前，先了解一下为什么要进行Fsimage的更新？
HDFS是以主从模式运行，其中的主就是我们的要讲的重点——NameNode。NameNode主要是管理文件系统的命名空间，它维护着文件系统树以及整棵树内所有的文件和目录。这些信息以两个文件形式永久的保存在本地磁盘上——命令空间镜像文件Fsimage、编辑日志文件edits。这两个文件是NameNode节点的核心文件。当NameNode启动时会首先读取Fsimage文件，并将目录树信息装载到内存中。而edits存储的是日志信息，在NameNode启动后所有对目录结构的增加、删除、修改等操作都会记录到edits文件中，并不会立即同步到fsimage中。
当NameNode结点关闭的时候，也不会将fsimage和edits文件进行合并，合并的过程实际在NameNode的启动过程中。当NameNode启动时会首先装载Fsimage文件，然后再来应用edits文件，最后将最新的目录树信息更新到新的Fsimage中，然后使用新的edits文件。
但是合并的时候会有一个问题，如果edits文件无比大的情况下，会导致合并过程很长，从而启动的时间也会变长，并且不可控，可能需要启动几个小时。所以此时就需要用SecondaryNameNode。它会按照一定的规则被唤醒，然后进行Fsimage文件与edits文件的合并，这样就可以防止edits文件过大。但是SecondaryNameNode只是NameNode的备份，以支持HA模式，且只是为了定期合并edits和Fsimage，以减轻NameNode的负载。
Fsimage的更新
Fsimage的更新需要有两个触发点，这两个触发点都在配置文件core-site.xml中进行配置。分别为fs.checkpoint.period【表示多长时间记录一次HDFS镜像，默认的是为一个小时】和fs.checkpoint.size【表示一次记录多大的size,eidts达到设置的大小后会自动触发合并，默认为64MB】。
- SecondaryNameNode会周期性的去检查eidts的大小，当edits达到设置的大小或者到了合并的时间会通过RollEditLog()方法进行合并。
- 首先会停止对当前edits的写入，并产生临时的edits.new文件，之后新的操作记录都写入edits.new里面。
- SecondaryNameNode通过HttpGet方法，从NameNode获取新的edits和fsimage文件。
- SecondaryNameNode合并edits和fsimage文件，并产生fsimage.ckpt文件。
- 然后SecondaryNameNode以HttpPost方式将Fsimage.ckpt发送到NameNode
- NameNode拿到fsimage.ckpt重命名为fsimage,即更新fsimage，fsimage更新完成后，将eidts.new文件重命名为edits文件。