FSEditLog记录

这几天搞namenode的重构,把namenode里的许多组件的内部结构给翻了出来,每个组件都是一套复杂的小系统。未免遗忘,先吧FsEditLog给记录下来吧。

FSEditLog是用来记录namenode对HDFS的namespace的修改操作进行日志记录的。在namenode中,namespace(指文件系统中的目录树,文件等元数据信息,不包括block信息)是被全部缓存在内存中的,所以一旦namenode重启或者宕机,那么重启的时候必须要有一种方法能够将整个namespace进行重建,namenode目前的实现是将namespace信息记录在一个叫做fsimage的二进制文件中,该文件中将每一个文件或者目录的信息视为一个记录,每条记录中包括该文件(或目录)的名称,大小,user,group,mtime,ctime等等信息,namenode重启的时候,就是根据读取这个fsimage文件中的信息来重构namespace目录树结构。但是,fsimage始终是磁盘上的一个文件,不可能时时刻刻都跟namenode内存中的数据结构保持同步,而是每过一段时间更新一次fsimage文件,以此来保持fsimage跟namenode内存namespace的尽量同步。而在一个新fsimage和上一个fsimage中间的namenode操作,就会被记录在editlog中,所以,namenode会对应一个fsimage文件和一个editlog文件,这里FSEditLog类就是用来管理这个editlog文件的。

如下表所示,editlog将对HDFS文件系统的修改操作分成14中,每一种操作都有相应的代号。从该表中可以看出,对HDSF文件系统进行修改的操作包括创建文件,删除,mkdir,rename,设置权限,设置所属用户名,设置所属组等等,对namespace的这些属性进行修改的操作都会被editlog记录下来。

对于每种操作,editlog中都会记录不同的信息,但是有一个共同的原则就是:能够反映这次修改对namespace所产生的变化,随后的fsimage和editlog进行merge的时候,能够产生正确的新的fsimage,以保证namenode的namespace的完整性。

拿mkdir来举例:假设客户端对hdfs运行了一个mkdir指令,那么当该操作在hdfs中成功执行后,editlog就会记录一条信息在edit文件中,该记录的格式如下:

path(String), timestamp(long), atime(long), username(String), groupname(String), permission(short)。
这条记录中就能反映出,该mkdir是创建了一个什么目录,它的时间戳是多少,access time是什么时候,user是谁,所属group是哪个组,permission位是多少。
这样,当下一次fsimage跟editlog进行merge后,新的fsimage中就会多出来一个目录,并且记录了相应的元信息。
op(byte) 默认值 说明
OP_INVALID -1  
OP_ADD 0  
OP_RENAME 1  
OP_DELETE 2  
OP_MKDIR 3  
OP_SET_REPLICATION 4  
OP_DATANODE_ADD(已过期) 5  
OP_DATANODE_REMOVE(已过期) 6  
OP_SET_PERMISSIONS 7  
OP_SET_OWNER 8  
OP_CLOSE 9  
OP_SET_GENSTAMP 10  
OP_SET_NS_QUOTA 11  
OP_CLEAR_NS_QUOTA 12  
OP_TIMES 13  
OP_SET_QUOTA 14  

 


你可能感兴趣的:(Java,Hadoop,permissions,string,merge,数据结构,delete,user)