元数据的存储机制　　

A、内存中有一份完整的元数据(内存meta data)

B、磁盘有一个“准完整”的元数据镜像（fsimage）文件(在namenode的工作目录中)

C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志（edits文件）

NameNode和Secondary NameNode元数据管理机制

客户端每次对文件的操作，如果涉及到元数据的更新（读除外），比如说更改文件的名称，路径，移动，复制，上传，删除等，除了查之外，其他增删改都会有可能涉及到与元数据的更改。dfs不支持客户端更改文件内容，只能在文件后面追加。

注：当客户端对hdfs中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功后，相应的元数据会更新到内存meta.data中。当日志里面累积的操作记录越来越多，与老的fsimage相差越来越大，这时候需要由Secondary NameNode定期把edits文件和老的fsimage做一个合并上传上NameNode替换掉老的fsimage，这时候NameNode上的fsimage文件和内存上的元数据永远保持在一个小的差距里面。NameNode工作时，它的元数据查询都是找内存的，不会去找fsimage，也不会去找edits。

 

XML处理器输出 fsimage 的 xml 文档，包含了 fsimage 中的所有信息，比如 inodeid 等。该处理器的输出支持XML工具的自动化处理和分析，由于XML语法格式的冗余，该处理器的输出也最大。实例如下：

[root@srv02 hadoop]# hdfs oiv -i fsimage 0000000000000000000116 -p XML -o fsimage.xml[root@srv02 hadoop]# cat fsimage.xml

edits文件是操作记录文件，也可以查看个究竟：

hdfs oev -i edits edits_0000000000000013356-0000000000000013357  -o edits.xml