在NameNode的${dfs.namenode.name.dir}/current目录下，有这样几个文件：
在数据库系统中，log是用于记录写操作的日志的，并使用该Log进行备份、恢复数据等工作。有关写的操作的记录的，目前见过了两种：关系型数据库的log，HBase的WALs等等都是这样的写操作的日志。
HDFS也采用了类似的机制。在HDFS中，会将第一次的文件操作，看作一个事务。譬如说一个文件的创建、文件内容追加、文件移动等等写操作。从这个角度来看呢，fsimage文件就相当于HDFS 的元数据的数据库文件了，而edit log就相当于是操作日志文件了。
Fsimage：
每个fsimage文件都会包括整个文件系统中所有的目录和文件inodes信息。每个inode是HDFS内部的一个代表文件、或者目录的元数据，如果inode代表一个文件，它包括：文件的备份级别、修改时间、访问时间、访问权限、block的size、所有blocks的构成等信息。如果inode代表一个目录，它包括：修改时间、权限、其它相关元数据等。
Edit log：
它在逻辑上，是一个实例（也就是说可以理解为一个对象），实际上是由多个文件组成的。每个文件都被称为一个segment，并以 edits_作为前缀，文件名后面的是事务id。
譬如上面的：edits_0000000000011403382-0000000000011403408 就代表该文件中放的是
事务Id为0000000000011403382到0000000000011403408之间的那些事务的信息。当客户端完成了一个写操作，并收到namenode的success的响应码时，Namenode才会将该事务信息写到editlog文件中。
为什么将事务信息处理后不直接写到fsimage中？
如果这样做的话，也就是每个write操作完毕时，都去更新fsimage文件，在一个大的文件系统中，文件就会变得很大，上GB都是有可能的，那么将是一个缓慢的过程。
先写到edit log中，怎么合并到fsimage中呢？
解决方案是启动一个Secondary namenode。它的存在就是在内存中生成Primary NameNode的fsimage文件。它的处理过程是这样的：
延伸阅读
- ssh框架 2016-09-30
- 阿里移动安全 [无线安全]玩转无线电——不安全的蓝牙锁 2017-07-26
- 消息队列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 论文笔记【图片目标分割】 2017-07-26
- 词向量-LRWE模型-更好地识别反义词同义词 2017-07-26
- 从栈不平衡问题 理解 calling convention 2017-07-26
- php imagemagick 处理 图片剪切、压缩、合并、插入文本、背景色透明 2017-07-26
- Swift实现JSON转Model - HandyJSON使用讲解 2017-07-26
- 阿里移动安全 Android端恶意锁屏勒索应用分析 2017-07-26
- 集合结合数据结构来看看(二) 2017-07-26
学习是年轻人改变自己的最好方式