Ext4文件系统架构分析三

  • A+
所属分类:运维教程

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) struct ext4_dir_entry_2找到叶子节点。叶子节点包括一个线性的struct ext4_dir_entry_2数组;所有这些项都哈希到相同的值。如果发生溢出,目录项简单地溢出到下一个叶子节点,哈希的least-significant位(内部节点的map)做相应设置。

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

Htree的根 struct dx_root

Ext4文件系统架构分析三

Htree的内部节点: struct dx_node

Ext4文件系统架构分析三

Htree 树根和节点中都存在的 Hash map struct dx_entry

Ext4文件系统架构分析三

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文件系统架构分析三

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

Ext4文件系统架构分析三

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

Ext4文件系统架构分析三

扩展属性值可以紧跟在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。

1.21.1 布局

日志布局

Ext4文件系统架构分析三

一个事务以描述符和一些数据或者block revocation链表开始。一个结束的事务总是以一个提交块结束。如果没有提交记录(或者校验和不匹配),事务在日志重演的时候将被丢弃。

1.21.2  数据块头部

日志中的每个数据块的开头都是一个12 bytes的数据结构 struct journal_header_s

Ext4文件系统架构分析三

1.21.3  超级块

日志的超级块比Ext4的超级块简单。保存在日志的超级块中是日志的关键数据。日志超级块使用数据结构struct journal_superblock_s表示,大小为1024 bytes。

Ext4文件系统架构分析三

1.21.4  描述数据块Descriptor Block

Descriptor Block包含一个日志数据块tags的数组,这些tags描述了日志中接下来的数据块的最终位置。

Ext4文件系统架构分析三

日志数据块tags具有如下格式:由数据结构struct journal_block_tag_s表示,可以是8,12,24或38bytes。

Ext4文件系统架构分析三

1.21.5  数据块Data Block

存放的是通过日志写到磁盘的数据块。但是如果数据块的前4 bytes与jbd2的魔数匹配,那么这些4 bytes用0代替,并且在Descriptor Block中设置escaped。
1.21.6  Revocation BlockRevocation block用于记录本事务中的数据块链表,取代任何潜在日志中的更陈旧的数据块这样可以加速恢复,因为陈旧的数据块不必写到磁盘。

Revocation block使用 struct jbd2_journal_revoke_header_s结构表示

Ext4文件系统架构分析三

1.21.7  提交块

提交快表明了一个事务已完整写到日志。一旦提交块到达日志,存储在该事务中的数据可以写到它们在磁盘中的最终位置。

提交快由数据结构struct commit_header表示:

Ext4文件系统架构分析三

转载自http://blog.chinaunix.net/uid-26430381-id-4559497.html

  • 我的微博
  • 这是微博的扫一扫
  • weinxin
  • 微信公众
  • 微信公众号扫一扫
  • weinxin

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

目前评论:48   其中:访客  43   博主  1

    • avatar 芭帜时毒娜乖歉杭蹈芍眉细捕戎壕菩医梅 9

      签到成功!签到时间:今日的上午10:15:18,每日打卡,生活更精彩哦!

      • avatar 亮傥把鞘悠滔露潮漳拔茁啡和偻卦涸局蹦 9

        签到成功!签到时间:今日的上午7:24:52,每日打卡,生活更精彩哦!

        • avatar 临必卮厩墩诟趁厍颖磁蒂参栏中信鸦淄逝 9

          签到成功!签到时间:今日的上午5:11:22,每日打卡,生活更精彩哦!

          • avatar 凭梢送钠侣咳慌缀让疽匦映糖赝慰抑探桶 9

            签到成功!签到时间:今日的上午2:52:25,每日打卡,生活更精彩哦!

            • avatar 弊乔特宋滩倒馗怨忻蓟傧拙颊缮惨衅灿兰 9

              签到成功!签到时间:今日的下午9:42:29,每日打卡,生活更精彩哦!