Ext4文件系统架构分析一

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

本文描述Ext4文件系统磁盘布局和元数据的一些分析,同样适用于Ext3和Ext2文件系统,除了它们不支持的Ext4的特性外。整个分析分两篇博文,分别概述布局和详细介绍各个布局的数据结构及组织寻址方式等。感兴趣的看官敬请留意和指导!

1. Ext4文件系统布局综述

一个Ext4文件系统被分成一系列块组。为减少磁盘碎片产生的性能瓶颈,块分配器尽量保持每个文件的数据块都在同一个块组中,从而减少寻道时间。以4KB的数据块为例,一个块组可以包含32768个数据块,也就是128MB。

1.1 磁盘布局

Ext4文件系统的标准磁盘布局如下:
Ext4文件系统架构分析一

Ext4文件系统主要使用块组0中的超级块和块组描述符表,在其他一些特定块组中有超级块和块组描述符表的冗余备份。如果块组中不含冗余备份,那么块组就以数据块位图开始。当格式化磁盘成为Ext4文件系统的时候,mkfs将在块组描述符表后面分配预留GDT表数据块(“Reserve GDT blocks”)以用于将来扩展文件系统。紧接在预留GDT表数据块后的是数据块位图与inode表位图,这两个位图分别表示本块组内的数据块与inode表的使用,inode表数据块之后就是存储文件的数据块了。在这些各种各样的块中,超级块、GDT、块位图、Inode位图都是整个文件系统的元数据,当然inode表也是文件系统的元数据,但是inode表是与文件一一对应的,我更倾向于将inode当做文件的元数据,因为在实际格式化文件系统的时候,除了已经使用的十来个外,其他inode表中实际上是没有任何数据的,直到创建了相应的文件才会分配inode表,文件系统才会在inode表中写入与文件相关的inode信息。

1.2 Flexible 块组(flex_bg)

Flexible 块组(flex_bg)是从Ext4开始引入的新特性。在一个flex_bg中,几个块组在一起组成一个逻辑块组flex_bg。Flex_bg的第一个块组中的位图空间和inode表空间扩大为包含了flex_bg中其他块组上位图和inode表。

比如flex_bg包含4个块组,块组0将按序包含超级块、块组描述符表、块组0-3的数据块位图、块组0-3的inode位图、块组0-3的inode表,块组0中的其他空间用于存储文件数据。同时,其他块组上的数据块位图、inode位图、inode表元数据就不存在了,但是SB和GDT还是存在的。
Ext4文件系统架构分析一
Flexible块组的作用是:

(1)  聚集元数据,加速元数据载入;

(2)  使得大文件在磁盘上尽量连续;

即使开启flex_bg特性,超级块和块组描述符的冗余备份仍然位于块组的开头。 Flex_bg中块组的个数由2^ext4_super_block.s_log_groups_per_flex 给出。

1.3 元块组(Meta Block Groups)

通常,在每个冗余备份的超级块的后面是一个完整的(包含所有块组描述符的)块组描述符表的备份。这样会产生一个限制,以Ext4的块组描述符大小64 Bytes计算,文件系统中最多只能有2^21个块组,也就是文件系统最大为256TB。

使用元块组Meta Block Groups特性,每个块组都包含该块组自己的描述符的冗余备份。因此可以创建2^33个块组,也就是文件系统最大1EB。48位数据块,每个块组128MB,因而可以创建2^33个块组。

元块组实际上是可以用一个块组描述符块来进行描述的块组集,简单的说,它由一系列块组组成,同时这些块组对应的块组描述符存储在一个块中。它的出现使得Ext3和Ext4的磁盘布局有了一定的变化,以往超级块后紧跟的是变长的GDT块,现在是超级块依然决定于是否是3,5,7的幂,而一个块组描述符块则存储在元块组的第一个,第二个和最后一个块组的开始处(见下图)
Ext4文件系统架构分析一
在两种情况下我们可能会用到这种新布局:

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

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

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

 

1.4 Lazy 块组初始化

如果块组中的相应标志已设置,那么块组中的inode位图和inode表将不被初始化。这样可以减少mkfs时间,如果开启了块组描述符校验和功能,甚至连块组都可以不初始化。

1.5 特殊inodes

Ext4预留了一些inode做特殊特性使用,见下表:

表 1  Ext4的特殊inode

Inode号    用途

0      不存在0号inode

1      损坏数据块链表

2      根目录

3      ACL索引

4      ACL数据

5      Boot  loader

6      未删除的目录

7      预留的块组描述符inode

8      日志inode

11     第一个非预留的inode,通常是lost+found目录

1.6 数据块和Inode分配策略

在机械磁盘上,保持相关的数据块相互接近可以总的磁头移动时间,因而可以加速磁盘IO。在SSD上虽然没有磁头转动,数据局部性可以增加每次IO请求的传输的数据大小,因而减少响应IO请求的传输次数。数据的局部性对单个擦除块的写入产生影响,可以加速文件重写的速度。因而尽可能减少碎片是必要的。inode和数据块的分配策略可以保证数据的局部集中。以下为inode和数据块的分配策略:

(1)  多块分配可以减少磁盘碎片。当文件初次创建的时候,块分配器预测性地分配8KB的磁盘空间给文件。当文件关闭的时候,未使用的空间当然也就释放了。但是如果推测是正确的,那么文件数据将写到一个多个块的extent中。

(2)  延迟分配。当一个文件需要更多的数据块引起写操作时,文件系统推迟决定新数据在磁盘上的存放位置,直到脏的buffer写到磁盘为止。

(3)  尽量保持文件的数据块与其inode在同一个块组中。可以减少磁盘寻道时间.

(4)  尽量保持同一个目录中的所有inodes与目录位于同一个块组中。这样的假设前提是一个目录中的文件是相关的。

(5)  磁盘卷被分成128MB的块组。当在根目录中创建目录时,inode分配器扫描块组并将新目录放到它找到的使用负荷最小的块组中。这可以保证目录在磁盘上的分散性。

(6)  即使上述机制无效,仍然可以使用e4defrag整理碎片文件。

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

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

发表评论

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

目前评论:42   其中:访客  39   博主  2

    • avatar 甘俳徒匈刂眯手痘铰已重仪搅焦倨柯毕渴 9

      签到成功!签到时间:今日的上午8:36:48,每日打卡,生活更精彩哦!

      • avatar 沸成杂嚷囊睦妇惺酒叛膛芬丛逗膊诒探儇 9

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

        • avatar 藕贸吭昭谥魄陶挥诙忍醚德吞撤执摆衫移 9

          签到成功!签到时间:今日的下午10:02:24,每日打卡,生活更精彩哦!

          • avatar 径馁炎峡囤赏云勺酥我此客善膊颐当母课 9

            签到成功!签到时间:今日的下午5:19:47,每日打卡,生活更精彩哦!

            • avatar 救纸丶盟分浦钢退伪飞愿皇智倌奄坊帽字 9

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

              • avatar 爬卮隙干幻囟何贤慈乔潜辞餐趁镁秦得低 9

                签到成功!签到时间:今日的上午9:21:07,每日打卡,生活更精彩哦!

                • avatar 们倥箍旨诺北烤俑车锤崩档颊忱扰爸仿淘 9

                  签到成功!签到时间:今日的上午3:16:38,每日打卡,生活更精彩哦!

                  • avatar 治几必涣目壕恫囤陶庸纹炙士还脸蓝葱杏 9

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

                    • avatar 既哑核苟竟低朗粗究厩汲期渍崩诠什庞诺 9

                      签到成功!签到时间:今日的下午7:14:59,每日打卡,生活更精彩哦!

                      • avatar 堵弦撇氖恿蒲捅估素品滔痔卵睾胺孛掳且 9

                        签到成功!签到时间:今日的上午9:16:17,每日打卡,生活更精彩哦!