关于hdfs源码的阅读，我这个小菜鸟觉得有这么两种方式去读，一是抓住它关键的数据结构，知道了他们是干什么用的，剩下的就是一些围着他们转的操作了；二是跟踪执行过程的流程式阅读，以mkdir为例，从client应用发出mkdir请求到传递给namenode，再在datanode上执行，这么一个过程详细地跟踪下来，就理解了一大片。两种路子没有孰优孰劣，配合使用或许更有效。本篇先从数据结构的角度分享一点自己读namenode部分源码的收获。
这是一张任何介绍hdfs的文章都会出现的架构图。采用的是master/slave模型，一个hdfs cluster包含一个NameNode和若干的DataNode，NameNode（以下简称nn）是master，主要负责管理hdfs文件系统，具体地包括namespace管理（其实就是目录结构），block管理（其中包括 filename->block，block->ddatanode list的对应关系）。nn提供的是始终被动接收服务的server，主要有三类协议接口：ClientProtocol接口、DatanodeProtocol接口、NamenodeProtocol接口，貌似还有一种，忘记了。DataNode(简称dn)主要是用来存储数据文件，hdfs将一个文件分割成一个个的block，这些block可能存储在一个DataNode上或者是多个DataNode上。dn负责实际的底层的文件的读写，如果客户端client程序发起了读hdfs上的文件的命令，那么首先将这些文件分成block，然后nn将告知client这些block数据是存储在那些dn上的，之后，client将直接和dn交互。
更多Hadoop相关信息见Hadoop 专题页面 ?tid=13
体系结构中还有个节点没画出来，Secondary NameNode，该部分主要是定时对NameNode进行数据snapshots进行备份，这样尽量降低NameNode崩溃之后，导致数据的丢失，其实所作的工作就是从nn获得fsimage和edits把二者重新合并然后发给nn，这样，既能减轻nn的负担又能保险地备份。
好了，下面开始正题。
不管是client还是dn的消息发到nn后最终都会落到FSnamesystem身上，这是一个重量级家伙，如图，对各种服务请求的处理都转交给它完成，它提供了对各种数据结构操作的接口，这些数据结构共同维护了整个namenode的元数据信息。
nn的主要数据结构有：
