（1）NameNode的内存中保存了庞大的目录树结构，这个结构用来保存文件目录结构和文件Block之间的映射，这种结构关系会固化在磁盘上，但是对树的改动频繁发生，什么时候将树写入磁盘呢？把每次操作应用到内存中的树上，并把操作记录成日志文件，每次操作不会改变固化在磁盘上的改动发生之前的目录树，适当的时候做一次固化操作并记录时间。
（2）NameNode上面的磁盘目录结构：
[hadoop@localhost dfs]$ ls -R name
name:
current image in_use.lock
name/current:
edits fsimage fstime VERSION
name/image:
fsimage
in_use.lock的功能和DataNode的一致。fsimage保存的是文件系统的目录树，edits则是文件树上的操作日志，fstime是上一次新打开一个操作日志的时间（long型）。NameNode成功载入一次fsimage就要把这个时刻记录在fstime中，fstime表示edits第一条记录开始记录的时刻。saveImage的时候需要先写入中间文件，防止中途断电。
image/fsimage是一个保护文件，防止0.13以前的版本启动（0.13以前版本将fsimage存放在name/image目录下，如果用0.13版本启动，显然在读fsimage会出错J）。也就是说写入fsimage要有两份。
（3）管理NameNode磁盘目录的是FSImage，也是继承Storage类的，和DataStorage类似，有升级回退机制，暂时不考虑。
（4）FSImage需要支持参数-importCheckpoint，该参数用于在某一个checkpoint目录里加载HDFS的目录信息，并更新到当前系统，该参数的主要功能在方法doImportCheckpoint中。该方法很简单，通过读取配置的checkpoint目录来加载fsimage文件和日志文件，然后利用saveFSImage（下面讨论）保存到当前的工作目录，完成导入。
（5）loadFSImage用来在多个目录中选择最新的fsimage和edit来载入，最新以及fsimage和edit的一致性由fstime保证，载入过程中对NameNode崩溃的处理要分析saveFSImage的过程在明白。
（6）saveFSImage()的功能正好相反，它将内存中的目录树持久化，很自然，目录树持久化后就可以把日志清空。saveFSImage()会创建edits.new，并把当前内存中的目录树持久化到fsimage.ckpt（fsimage现在还存在），然后重新打开日志文件edits和edits.new，这会导致日志文件edits和edits.new被清空。最后，saveFSImage()调用rollFSImage()方法。
rollFSImage()上来就把所有的edits.new都改为edits（经过了方法saveFSImage，它们都已经为空），然后再把fsimage.ckpt改为fsimage。
（7）saveFSImage和loadFSImage为了考虑NameNode突然崩溃的情况使磁盘固化操作得以回滚创建了中间状态，中间状态的描述方式就是在磁盘上建立临时文件。
