我们看一下这是 NameNode 所在机器的：/home/admin/software/hadoop-2.7.2/hadoop-data/dfs/name/current 路径下的 edits文件和 fsimage文件：
为什么会有这么多 edits文件，这些edits 文件创建的时间都是间隔1个小时，这是因为每隔1小时，secondaryNameNode 都会对 edits 和 fsimage 进行一次合并，合并之后，旧的 edits 并不会被删除，依旧被保留。
edits_inprogress… 文件：最新的一个edtis文件，用来记录用户的上传、删除操作。
那我们看 fsimage 只保留两个文件。
fsimage… .md5 是对应文件的md5值文件，用来保证 fsimage的一致性的。
seen_txid：里面保存了最新的一个 edits 文件的名字 最后的三位：107.
NameNode 格式化后 第一次启动时，会创建一个 edits 和 fsimage 文件，后面再次启动时，直接加载 每个 edits 和最新的 fsimage 文件。
下面来看几个问题：
1、为什么要每个 edits 都加载呢？fsimage不是已经保存之前 edits日志当中转换后的 元数据了么？
这是为了再做一次校验的工作，确保加载到内存当中的元数据是可靠的。
2、Edits 文件是用来做什么的？为什么要保留这么多 edtis文件，像 fsimage一样保存一两个文件不就可以了么？
这个要和 fsimage 、secondary’NameNode 放在一起来理解
1） edits是用来存放 用户的 上传、删除请求的日志的。当用户上传成功，这条记录会保存到 内存元数据当中。也就是说，edits是作为一个中间文件。
2） 当 secondarynamenode 对 edtis 和 fsimage 进行合并时，会创建一个新的 edits 文件，以接收在合并期间 来的新的 用户上传请求。
所以，每次触发 secondaryname 的 checkpoint（也就是对edits和 fsimage 合并），都会产生一个新的 edtis 文件。
3） 为什么不删除以前的 edtis 文件？其实第1个问题已经做了回答。
3、旧的 edtis 文件一直会保留，会不会有一天 edits把空间沾满了啊？还有 fsimage，它保留了所有 block块的信息，总有一天会很大吧？
这个问题其实我们不用担心，因为 edtis 和 fsimage 只是保留了 每个文件的位置等的信息，这些信息经过很长时间也不会占用多少空间的。
但也会遇到小文件太多的问题，比如我们把 block块的大小设为 128M，虽然小于block大小的小文件不会占用整个HDFS block空间，但是较多的小文件会占用更多的NameNode的内存，因为文件或者目录在内存中均以对象的形式存储，每个对象约占150byte，如果有1000 0000个小文件，则namenode大约需要2G空间。这样namenode内存容量严重制约了集群的扩展。 其次，访问大量小文件速度远远小于访问几个大文件。HDFS最初是为流式访问大文件开发的，如果访问大量小文件，需要不断的从一个datanode跳到另一个datanode，严重影响性能。
