Ext4文件系统架构分析(三) ——目录哈希、扩展属性与日志

最新推荐文章于 2024-06-30 04:15:00 发布

eeblacksmith

最新推荐文章于 2024-06-30 04:15:00 发布

阅读量7k

点赞数

分类专栏： linux文件系统文章标签： ext4

linux文件系统专栏收录该内容

23 篇文章 11 订阅

订阅专栏

原文来自 http://blog.chinaunix.net/uid-28989651-id-3981448.html

1.19 哈希树目录

线性目录项不利于系统性能提升。因而从ext3开始加入了快速平衡树哈希目录项名称。如果在inode中设置EXT4_INDEX_FL标志，目录使用哈希的B树（hashed btree ，htree）组织和查找目录项。为了向后只读兼容Ext2，htree实际上隐藏在目录文件中。

Ext2的惯例，树的根总是在目录文件的第一个数据块中。“.”和“..”目录项必须出现在第一个数据块的开头。因而这两个目录项在数据块的开头存放两个struct ext4_dir_entry_2结构，且它们不存到树中。根结点的其他部分包含树的元数据，最后一个hash->block map查找到htree中更低的节点。如果dx_root.info.indirect_levels不为0，那么htree有两层；htree根结点的map指向的数据块是一个内部节点，由一个minor hash索引。Htree中的内部节点的minor_hash->block map之后包含一个零化的(zeroed out) structext4_dir_entry_2找到叶子节点。叶子节点包括一个线性的struct ext4_dir_entry_2数组；所有这些项都哈希到相同的值。如果发生溢出，目录项简单地溢出到下一个叶子节点，哈希的least-significant位（内部节点的map）做相应设置。

以htree的方式遍历目录，计算要查找的目录文件名称的哈希值，然后使用哈希值找到对应的数据块号。如果树是flat，该数据块是目录项的线性数组，因而可被搜索到；否则，计算文件名称的minor hash，并使用minor hash查找相应的第三个数据块号。第三个数据块是目录项线性数组。

Htree的根：struct dx_root

Htree的内部节点： struct dx_node

Htree 树根和节点中都存在的 Hashmap： struct dx_entry

1.20 扩展属性EA

扩展属性（xattrs）通常存储在磁盘上的一个单独的数据块中，通过inode.i_file_acl*引用。扩展属性的第一应用是存储文件的ACL以及其他安全数据(selinux)。使用user_xattr挂载选项就可为用户存储以“user”开头的所有扩展属性。这样的限制在3.0内核中已经消失。

可以在两个地方找到扩展属性：一是在一个inode项结尾到下一个inode项开头的地方；二是inode.i_file_acl指向的数据块之中，到3.0为止，这个数据块中不包含指向第二个扩展属性数据块的指针。理论上可以将每个属性值存储到一个单独的数据块中，但是3.0内核为止仍然没有这样做。

当扩展属性不存储在一个inode之后的时候，就会有一个头部ext4_xattr_ibody_header

扩展属性数据块的开头是ext4_xattr _header

紧跟在ext4_xattr_ibody_header或者ext4_xattr _header后面的是结构数组 struct ext4_xattr_entry

扩展属性值可以紧跟在ext4_xattr_entry项表后面。考虑4 bytes对齐。扩展属性值从扩展属性数据块的末尾开始向ext4_xattr_header / ext4_xattr_entry表的方向增长。当发生溢出时，溢出的部分放到一个单独的磁盘数据块上。

1.21 日志（JBD2）

文件系统在磁盘上保留一段小的连续区域(默认128MB)，作为尽可能需要快速写入磁盘的“重要”数据的存放地。一旦该重要数据事务完全写到磁盘，将其从磁盘写缓存中刷出。被提交的数据一份记录也被写到日志。一段时间后，日志在擦除提交记录前将事务写到它们在磁盘上的最终位置(可能包含大量的寻道或者大量的读-写-擦除)。

从性能方面考虑，Ext4默认直接将文件系统元数据写到日志。因而不能保证文件数据块的一致性。

日志的inode为8。日志inode的前68 bytes复制了ext4 超级块。日志文件在文件系统中是普通文件，但是隐藏不可见。日志文件通常消耗一个完整的块组，可以通过mke2fs将日志文件放在磁盘的中间。

Ext4和Ocfs2都使用JBD2。