Edits和Fsimage文件
知识点
1.当执行格式化指令时，会在指定的tmp目录下，生成dfs/name目录。
此目录是namenode服务器存储元数据的目录
2.当格式化后，启动HFDS前，会生成一个最初的fsimage_0000000000000000000文件
3.在 dfs/data目录，这是datanode节点存储数据块的目录。
4.元数据的存储目录和数据节点的目录的路径可以分开指定
5.在dfs/name/in_use.lock ，这个文件的作用是防止在同一台服务器上启动多个namenode,避免管理紊乱。
6.当启动HDFS时，会生成Edits文件。
7.HDFS有事务id的概念，当HDFS每接收一个事务操作（比如：mkdir put mv），都会分配响应的事务id，然后写到Edits文件中。
Persistent Transaction IDs
One of the subtasks of HDFS-1073 is HDFS-1521, which makes the transaction IDs persist across restarts of
the NameNode. That is to say, the first edit on a newly formatted NN will have transaction ID 1, and that
ID will never be reused for the lifetime of the namesystem (even after restarts and checkpoints).
8.每生成一个新的Edits文件，Edits文件中都会以BEGIN LOG 开头，当一个Edits文件写完后，会以END LOG结尾。即在BEGIN LOG ——END LOG 存储的是这个Edits文件所有的事务记录
1. OP BEGIN LOG SEGMENT - this transaction is written at the start of every new edit log file. It currently
contains no data, but may later contain some special checkpointing information or metadata about the
namespace.
2. OP END LOG SEGMENT - this transaction is written at the end of an edit log before it is closed. This is
used as a sanity check that the log was gracefully closed, and is also useful to allow the BackupNode
to synchronize its log roll with the primary NameNode. In the future it might be extended to include
some kind of checksum information about the log file.
9.edits_inprogress文件的作用是记录当前正在执行的事务文件。后面的编号是以上一次Txid+1来命名的。
10.初次使用HDFS时，有一个默认的Edits和Fsimage的合并周期（1分钟），以后在使用HDFS的过程中，edits_inprogress合并的条件：①到达合并周期（3600s) ②执行手动合并指令 ③停止HDFS再启动HDFS
11.上传文件底层会拆分成如下的事务过程：
①OP_ADD 将文件加入到指定的HDFS目录下，并以._Copyging_结尾，表示此文件还未写完
②ALLOCATE_BLOCK_ID 为文件分配块ID
③SET_GENSTAMP_V2 为块生成时间戳版本号，是全局唯一的
④ADD_BLOCK 写块数据
⑤OP_CLOSE 表示块数据写完
⑥OP_RENAME_OLD 将文件重命名，表示写完
12.当停止HDFS在启动HDFS,Edits和Fsimage的合并机制为：
When an image is saved or uploaded via a checkpoint, the validity rule is as follows: any fsimage with
txid N must incorporate all edits from logs containing earlier transaction IDs. So, if we enter safe mode and
call saveNamespace on the above example, we end up with:
1. fsimage 0 - original empty imagge
2. edits 1-10 - edits before first roll
3. edits 11-12 - edit log containing special BEGIN LOG SEGMENT and END LOG SEGMENT transactions but
no actual namespace changes.
4. fsimage 12 - all edits from both edit logs have bee incorporated into namespace
5. edits inprogress 13 - the edit log where new edits will be appended
13.seen_txid记录是的最新的edits_inprogress文件末尾的数字
14.Fsimage_N文件存储的N号事务前的所有的元数据信息
15.fsimage_0000000000000000002.md5存储的是Fsimage文件的md5校验码
查看Edits文件和Fsimage文件
hdfs oev -i edits_0000000000000000001-0000000000000000003 -o edits.xml
hdfs oiv -i fsimage_0000000000000000012 -o fsimage.xml -p XML
FSimage介绍
把文件和目录的元数据信息持久化地存储到fsimage文件中，HDFS每次启动时从中将元数据加载到内存中构建目录结构树，之后的操作记录在edits log中
定期将edits与fsimage合并刷到fsimage中
loadFSImage(File curFile)用于从fsimage中读入Namenode持久化的信息。fsimage中保存的元数据信息格式如下，hdfs加载和写入时都按照该格式进行
fsimage是一个二进制文件，当中记录了HDFS中所有文件和目录的元数据信息。
格式：
| ImageVersion |
NameSpaceId |
NumFiles |
genStamp |
|
| Path |
BlockNums |
mtime |
atime |
|
| BlokId |
BlockSize |
BlockNumBytes |
StorgeInfo |
genStamp |
| nsquota |
dsquota |
username |
groupname |
permission |
1）ImageVersion Fsimage文件的版本号，每生成一个新的Fsimage文件，就会有一个版本号
2）NameSpaceId :namenode的命名空间id，用于标识namenode。每当执行一次格式执行令时，就会生成新的
3）NumFiles：整个HDFS存储的文件数
4）genStamp:有目录创建的时间戳，块生成的时间戳
5）path：文件路径
6）BlockNums：文件的块数量
7）mtime:上传时间
8）atime:访问时间
9）BlockId：块编号
10）BlockSize:切块大小（128MB)
11）BlockNumBytes：块的实际大小
12）StorgeInfo：块存储的datanode节点信息
13）nsquota：目录的命名空间大小配合，默认是-1 表示目录可以无限存储
14）dsquota：目录的磁盘空间存储配额，默认是-1
15）username：目录的创建者
16）groupname：目录创建者的属组
17）permission：目录的权限
HDFS启动时，会将这些信息读入内存之后，构造一个文件目录结构树，将表示文件或目录的节点填入到结构中。