[ext4]04 磁盘布局 - Meta Block Groups

Meta Block Groups,可以翻译为元块组集。

如果不采用Meta Block Groups特性,在每个冗余备份的超级块的后面是一个完整的(包含所有块组描述符的)块组描述符表的备份。如前所述(group分析中已经说明,group最大为128M,即2^27 bytes),那么一个group全部存储groups元数据,才会有2^27 / 64=2^21个,更何况,也无法全部用来存储groups元数据。这样会产生一个限制,以Ext4的块组描述符大小64 Bytes计算,文件系统中最多只能有2^21个块组,也就是文件系统最大为256TB。

使用Meta Block Groups特性,整个文件系统被分成多个元块组集(metablock groups),每个元块组集都是一簇块组组成(簇的含义:一系列物理地址连续的单元),组成metablock groups的块组描述符都存放在一个block中。对于block大小为4K的Ext4文件系统,一个元块组包含64个块组,也就是64G的磁盘空间(128M*64=8G)。Meta Block Groups特性将存放在系统第一个块组的元数据分割存放在多个MetaBlock Groups中。

因为Ext4支持的是48bits block寻址方式,所以最大卷大小为2^48个block,2^48*2^12=2^60B=1EB,而每个group为128M=2^27B,所以有2^60/2^27=2^33个group。

那么为什么是48bits寻址而不是64bits哪,虽然在ext4_super_block中blocks寻址的高位和地位均为32bits:

__le32 s_blocks_count_lo; /* Blocks count */

__le32 s_blocks_count_hi; /* Blocks count */

原因在于:在使得ext4系统完全支持64bits block寻址时,还有一些限制没有解决,但是可以相信的是,在以后某个时候肯定会完全支持64bits,但是我像1EB已经足够。

【There are some limitations that would need to be fixed before making Ext4 fully 64-bit capable, which have not been addressed in Ext4. 
The Ext4 data structures have been designed keeping this in mind, so a future update to Ext4 will implement full 64-bit support at some point. 1 EB will be enough (really :)) until that happens. (Note: The code to create filesystems bigger than 16 TB is -at the time of writing this article- not in any stable release of e2fsprogs. It will be in future releases.)】

Meta Block Groups特性的出现使得Ext3和Ext4的磁盘布局有了一定的变化,以往超级块后紧跟的是变长的GDT块,现在是超级块依然决定于是否是3,5,7的幂,而块组描述符集则存储在元块组的第一个,第二个和最后一个块组的开始处(见下图)


在两种情况下我们可能会用到这种新布局:

(1) 文件系统创建时。用户可以指定使用这种布局。

(2) 当文件系统增长而且预留的组描述符块耗尽时。目前超级块中有一个域s_first_meta_bg用于描述第一个使用元块组的块组。

当增加新块组时,我们不需要给组描述符表预留空间,而是在当前文件系统后面直接添加新的元块组就可以了。

  • 1
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 5
    评论
本文基于kernel4.19.67版本分析。 基于如下命令完成写测试 time dd if=/dev/zero of=./test.bin count=2 bs=1G oflag=direct 同样的命令发现xfs的性能是9.4M/s, ext4是6.6M-8.8M/s, 且波动很大,大部分时间集中在7.5M/sz每秒。 基于上面的现象深入分析基于xfs和ext4分别direct方式写usb时的性能差异,找到了一种提升写usb性能的办法。 同时详细记录并描述了从vfs_write开始,到hcd层写数据的流程及关键点。 经过分析得到了如下几个知识点: a)xfs和ext4 即使是direct方式下写数据的方式也不一样,xfs依赖iomap是将数据(struct bio)提交到block层; ext4依赖filemap,最终依赖fs/direct-io将数据(struct bio )提交到block b)iomap提交到block层的数据以2M连续内存的页的方式提交,direct-io没有保证连续内存,虽然数据大小也是2M. 这是xfs和ext4出现性能差异的主要原因。 c)每次2M数据大小的限制是block层设置的 d)block层以回调函数(queue_rq)调用方式将数据(struct request)包装成struct blk_mq_queue_data格式提次到scsi层 e)scsi以消息方式将blk_mq_queue_data数据包装成struct scsi_cmnd格式发送给驱动usb-storage f)block层的缓冲区大小虽然有2M, 但是真正提交到scsi层时(scsi进一步提交到usb-storage)会根据设备本身的配置来拆分。如默认按120K来拆分 g)经过分析发现影响性能的点主要有一点,一个是max_sectors大小的配置,如果配置为4096扇区大小=2M, 可以将ext4的性能从7.5M/s提高到9.5M/s. xfs可以从9.4M/s提高到10.4M/s h)xfs比ext4快的原因是因为xfs申请的内存页是连续的页,DMA可以更快运行,但是ext4没有保证,所以xfs比ext4明显快。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

YoungerChina

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值