fsimage与edits合并为新的fsimage后，文件block块查找时是怎么样的一个查找顺序？

fsimage与edits合并为新的fsimage后，文件block块查找时是怎么样的一个查找顺序？fsimage与edits合并为新的fsimage后，文件block块查找时是怎么样的一个查找顺序？
edits是表示操作，fsimage表示镜像，合并之后又是一个备份镜像，可否这样理解，fsimage就是在namenode上面的一个操作集合的备份？

自己来个沙发吧，没人回复我？

fsimage并非操作集合，而是记录了一些文件的信息，block并没有持久化在namenode，也就是说并没有保存在硬盘中，而是在hadoop启动的时候，由datanode上报自己的block，然后namenode将其保存在了BlocksMap了，我们根据BlocksMap，就可以找到相应的block了。



详细如下：


fsimage保存有如下信息：
1.         首先是一个image head，其中包含：
a)         imgVersion(int)：当前image的版本信息
b)        namespaceID(int)：用来确保别的HDFS instance中的datanode不会误连上当前NN。
c)         numFiles(long)：整个文件系统中包含有多少文件和目录
d)        genStamp(long)：生成该image时的时间戳信息。
2.         接下来便是对每个文件或目录的源数据信息，如果是目录，则包含以下信息：
a)         path(String)：该目录的路径，如”/user/build/build-index”
b)        replications(short)：副本数（目录虽然没有副本，但这里记录的目录副本数也为3）
c)         mtime(long)：该目录的修改时间的时间戳信息
d)        atime(long)：该目录的访问时间的时间戳信息
e)         blocksize(long)：目录的blocksize都为0
f)         numBlocks(int)：实际有多少个文件块，目录的该值都为-1，表示该item为目录
g)        nsQuota(long)：namespace Quota值，若没加Quota限制则为-1
h)        dsQuota(long)：disk Quota值，若没加限制则也为-1
i)          username(String)：该目录的所属用户名
j)          group(String)：该目录的所属组
k)        permission(short)：该目录的permission信息，如644等，有一个short来记录。
3.         若从fsimage中读到的item是一个文件，则还会额外包含如下信息：
a)         blockid(long)：属于该文件的block的blockid，
b)        numBytes(long)：该block的大小
c)         genStamp(long)：该block的时间戳

BlocksMap的内部数据结构如下：

更详细内容参考：

深度了解namenode---其 内部关键数据结构原理简介

hadoop详细了解5个进程的作用