Hadoop源代码分析（二三）

下面我们来分析FSDirectory。其实分析FSDirectory最好的地方，应该是介绍完INode*以后，FSDirectory在INode*的基础上，保存了HDFS的文件目录状态。系统加载FSImage时，FSImage会在FSDirectory对象上重建文件目录状态，HDFS文件目录状态的变化，也由FSDirectory写日志，同时，它保存了文件名à数据块的映射关系。

FSDirectory只有很少的成员变量，如下：

  final FSNamesystem namesystem;
  final INodeDirectoryWithQuota rootDir;
  FSImage fsImage;
  boolean ready = false;

其中，namesystem，fsImage是指向FSNamesystem对象和FSImage对象的引用，rootDir是文件系统的根，ready初值为false，当系统成功加载FSImage以后，ready会变成true，FSDirectory的使用者就可以调用其它FSDirectory功能了。

FSDirectory中剩下的，就是一堆的方法（我们不讨论和MBean相关的类，方法和过程）。

 

loadFSImage用于加载目录树结构，它会去调用FSImage的方法，完成持久化信息的导入以后，它会把成员变量ready置为true。系统调用loadFSImage是在FSNamesystem.java的initialize方法，那是系统初始化重要的一步。

addFile用于创建文件或追加数据时创建INodeFileUnderConstruction，下图是它的Call Hierachy图：

 

addFile首先会试图在系统中创建到文件的路径，如果文件为/home/hadoop/Hadoop.tar，addFile会调用mkdirs（创建路径为/home/hadoop，这也会涉及到一系列方法），保证文件路径存在，然后创建INodeFileUnderConstruction节点，并把该节点加到目录树中（通过addNode，也是需要调用一系列方法），如果成功，就写操作日志（logOpenFile）。

unprotectedAddFile也用于在系统中创建一个目录或文件（非UnderConstruction），如果是文件，还会建立对应的block。FSDirectory中还有好几个unprotected*方法，它们不检查成员变量ready，不写日志，它们大量用于loadFSEdits中（这个时候ready当然是false，而且因为正在恢复日志，也不需要写日志）。

addToParent添加一个INode到目录树中，并返回它的上一级目录，它的实现和unprotectedAddFile是类似的。

persistBlocks比较有意思，用于往日志里记录某inode的block信息，其实并没有一个对应于persistBlocks的写日志方法，它用的是logOpenFile。这个大家可以去检查一下logOpenFile记录的信息。closeFile对应了logCloseFile。

addBlock和removeBlock对应，用于添加/删除数据块信息，同时它们还需要更新FSNamesystem.java中对应的信息。

unprotectedRenameTo和renameTo实现了UNIX的mv命令，主要的功能都在unprotectedRenameTo中完成，复杂的地方在于对各种各样情况的讨论。

setReplication和unprotectedSetReplication用于更新数据块的副本数，很简单的方法，注意，改变产生的对数据块的删除/复制是在FSNamesystem.java中实现。

setPermission，unprotectedSetPermission，setOwner和unprotectedSetOwner都是简单的方法。

Delete和unprotectedDelete又是一对方法，删除如果需要删除数据块，将通过FSNamesystem的removePathAndBlocks进行。

……(后续的方法和前面介绍的，都比较类似，都是一些过程性的东西，就不再讨论了)