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进行。

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

你可能感兴趣的:(数据结构,hadoop,unix)