Ext4文件系统架构分析(二)

   接着上一篇博文,继续分析Ext4磁盘布局中的元数据。

1.7 超级块

超级块记录整个文件系统的大量信息,如数据块个数、inode个数、支持的特性、管理信息,等待。

如果设置sparse_super特性标志,超级块和块组描述符表的冗余备份仅存放在编号为0或3、5、7的幂次方的块组中。如果未设置sparse_super特性标志,冗余备份存在与所有的块组中。以下是2.6.32.18内核中对Ext4超级块的描述:

 

3.0的内核中,Ext4的超级块加入了以下相关元数据:快照、文件系统错误处理相关、挂载选项、配额文件inode、超级块校验和等,见下图。目前没有深入研究这些新的元数据。

 

1.8 块组描述符

一个块组中,具有固定位置的数据结构是超级块和块组描述符。其他数据结构位置都可以不固定。Flex_bg机制使用这个性质将几个块组聚合成一个flex块组,将flex_bg中所有位图和inode 表放到flex_bg的第一个块组中。详细情况可以参考我的上一篇Ext4分析博文的Flexible 块组(flex_bg)部分。


      如果设置了meta_bg特性标志,几个块组结合成一个meta group。在meta_bg的情况下,在meta group中的第一个和最后两个块组中仅包含meta group中的块组的块组描述符。Flex_bg和Meta_bg互斥因而不能共同出现。

 

1.9 数据块位图与inode位图

数据块位图跟踪块组中数据块使用情况。Inode位图跟踪块组中Inode使用情况。每个位图一个数据块,每一位用0或1表示一个块组中数据块或inode表中inode的使用情况。如果一个数据块大小是4KB的话,那一个位图块可以表示4*1024*8个数据块的使用情况,这也是单个块组具有的最大数据块个数。这样可以算出一个块组大小是128MB。当然一个位图块也可以表示4*1024*8个inode的使用情况,但是实际上一个块组中即使存满了文件,也不会用到这么多的inode,因为实际系统中基本不会出现所有文件大小都小于等于1个数据块大小的情况。实际上一个块组中有多少个inode,在块组描述符中是确定的,在文件系统格式化过程中也会看到这个数值,如果没记错的话,大概是每4个还是8个数据块分配一个inode空间。

 

1.10 Inode表

为了找到与一个文件相关的信息,必须遍历目录文件找到与文件相关的目录项,然后加载inode找到该文件的元数据。Ext4在目录项中用一位存储了文件类型(通常存储在inode中)的拷贝,这对性能提升有益。Inode表的大小为ext4_super_block.s_inode_size * ext4_super_block.s_inodes_per_group Bytes。 

     
 Ext4的inode的数据结构大小为156 bytes,但是Ext4的标准inode的大小是256 bytes。

 

1.11 查找inode

每个块组包含ext4_super_block.s_inodes_per_group个inodes。因为0号inode不存在,可以通过如下的算式计算inode所在的块组:

bg=(inode_num -1)/ ext4_super_block.s_inodes_per_group

inode在块组中inode表中的索引index可以通过如下的算式计算:

index=(inode_num -1) % ext4_super_block.s_inodes_per_group

inode在inode表中的地址偏移为:

offset=index * ext4_super_block.s_inode _size

 

1.12 inode.i_block0[]s的内容

取决于文件类型,inode.i_blocks[]使用的方式不同。一般来说,常规文件和目录用inode.i_blocks[]作为文件数据块索引信息,特殊文件将inode.i_blocks[]用于特殊用途。常规文件用inode.i_blocks[]作为文件数据块索引信息的三级索引结构会在后面直接、间接块地址中详细介绍。

 

1.13  符号链接

如果符号链接的目标字符串长度小于60字节,那么就将其存储在inode.i_blocks[]中,inode中inode.i_blocks[]占据的大小刚好是60KB。这里要注意到的是,有些文件其内容是跟文件的元数据放在一起的,因而就没有了数据块。也就是说不是每个文件数据都必然占据着一个数据块。

 

1.14 直接/间接块地址

 Ext2/Ext3中数据块映射方式如下表

 

 

1.15   Extent 树

Ext4中用extent树代替了逻辑块映射。使用extents,用一个struct ext4_extent结构就可以映射多个数据块,减少元数据块的使用。如果设置了flex_bg,甚至可以用一个extent分配一个非常大的文件。使用extent特性,inode必须设置extents flag。

Extents以树的方式安排。Extent树的每个节点都以一个ext4_extent_header开头,如果节点是内部节点(ext4_extent_header.eh_depth>0),ext4_extent_header后面紧跟的是ext4_extent_header .eh_entries个索引项struct ext4_extent_idx,每个索引项指向该extent树中一个包含更多的节点的数据块。如果节点是叶子节点(ext4_extent_header.eh_depth==0),ext4_extent_header后面紧跟的是ext4_extent_header .eh_entries个struct ext4_extent数据结构。这些ext4_extent结构指向文件数据块。Extent树的根结点存储在inode.i_blocks中,可以存储文件的前4个extents而不需额外的元数据块。

ext4_extent_header:

struct ext4_extent_idx:extent树的内部节点,也称为索引节点。

ext4_extent:extent树的叶子节点。

 

 

1.16 Extent树数据块校验和:可能加入的新元数据

由于extent树的根在inode中,因而Extent树数据块指extent树的除根据节点外的所有内部节点和叶子节点。Extent的树根节点和叶子节点的数据块中存储完xt4_extent_idx和xt4_extent数据结构后至少会留下4 ((2^x%12)>=4) bytes的空间。因而可以加入一个结构struct ext4_extent_tail,其中存储32位的校验和。位于inode中的4个extents无需校验和,因为inode已经做了校验和。

 

1.17 目录项

Ext4文件系统中,一个目录差不多是一个平面文件,映射任意长度的字符串到文件系统中的一个inode。文件系统中存在多个目录项引用同一个inode——硬链接,这也是硬链接不能链接其他文件系统中的文件的原因。

 

1.18 线性(经典)目录

缺省地,目录文件中包含一个线性的目录项数组。未使用的目录项标记为inode =0。Ext4文件系统默认地使用struct ext4_dir_entry_2记录目录项,除非没有设置filetype特性标志。在没有设置filetype特性标志的情况下,使用struct ext4_dir_entry记录目录项。
  

 

时间: 2024-10-17 01:11:19

Ext4文件系统架构分析(二)的相关文章

Ext4文件系统架构分析(一)

本文描述Ext4文件系统磁盘布局和元数据的一些分析,同样适用于Ext3和Ext2文件系统,除了它们不支持的Ext4的特性外.整个分析分两篇博文,分别概述布局和详细介绍各个布局的数据结构及组织寻址方式等.感兴趣的看官敬请留意和指导! 1. Ext4文件系统布局综述 一个Ext4文件系统被分成一系列块组.为减少磁盘碎片产生的性能瓶颈,块分配器尽量保持每个文件的数据块都在同一个块组中,从而减少寻道时间.以4KB的数据块为例,一个块组可以包含32768个数据块,也就是128MB. 1.1 磁盘布局 Ex

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

struct dx_root Htree的内部节点: struct dx_node Htree 树根和节点中都存在的 Hash map: struct dx_entry   1.20 扩展属性EA 扩展属性(xattrs)通常存储在磁盘上的一个单独的数据块中,通过inode.i_file_acl*引用.扩展属性的第一应用是存储文件的ACL以及其他安全数据(selinux).使用user_xattr挂载选项就可为用户存储以"user"开头的所有扩展属性.这样的限制在3.0内核中已经消失.

Linux的EXT4 文件系统的历史、特性以及最佳实践

让我们大概地从 EXT4 的历史.特性以及最佳实践这几个方面来学习它和之前的几代 EXT 文件系统有何不同. 在之前关于 Linux 文件系统的文章里,我写过一篇 Linux 文件系统介绍 和一些更高级的概念例如 一切都是文件.现在我想要更深入地了解 EXT 文件系统的特性的详细内容,但是首先让我们来回答一个问题,"什么样才算是一个文件系统 ?" 一个文件系统应该涵盖以下所有特点: 数据存储: 对于任何一个文件系统来说,一个最主要的功能就是能够被当作一个结构化的容器来存储和获取数据.

android. mvc,mvp,mvvm架构分析

问题描述 android. mvc,mvp,mvvm架构分析 android现在流行三种架构,mvc,mvp,mvvm网上介绍的文档很多都介绍的比较浅,最重要的是没有完整的比较大的项目结合分析, 解决方案 本质上来说,mvc mvp mvvm是差不多的东西,只是在model,viewmodel和businessmodel的职责划分上略有不同.而且在"完整的比较大的项目",其实根本不能教条使用教科书上的某一种模式."介绍的文档很多都介绍的比较浅"恰恰说明了这一点--把

核心业务需求及逻辑架构分析

12306的已知信息.数据及问题 需求分析(一)-- 售票系统领域知识(区间票.订票.预留票) 需求分析(二)-- 涉众.用户体验 核心业务需求及逻辑架构分析 需求分析(三)-- 票仓 票仓设计(一)-- 预生成车票方案的优缺点 票仓设计(二)-- 区间二进制方案的优缺点 票仓设计(三)-- 平衡方案的优缺点 票务并发冲突处理原则设计(基于平衡方案) 缓存逻辑架构设计 数据库逻辑设计 灾难备份与恢复 快要太监了 :-( 由于各种个人原因, 铁道部的这个博文系列中止了很久.最近终于连自己都不好意思

NopCommerce架构分析之(八)多语言支持_自学过程

系统支持的语言是有类:Language表示: 多语言资源对应的类为:LocalizedProperty: 当先选择某种语言存储在类中:GenericAttribute: 多语言可以导出为XML文件,当然也支持导出. IWorkContext及其实体类WebWorkContext为当前运行上下文:用户的登录信息以及一些上下文环境设置都保存在此类中. 具体包括:当前用户信息:CurrentCustomer:当前用户Cookie:货币:语言:税的类型:供应商等: 展现多语言资源的方式有几种: 一.在自

Linux中ext3与ext4文件系统区别

ext3还是使用15个inode来查找数据块,前12个为直接数据块,直接指向存储数据的数据块,接下来分别为一级间接块,二级间接块,三级间接块,如下图: 其中point本来也是数据块,现在拿来做数据块的索引用,其中ext3的头文件定义为:__u32 i_block[EXT3_N_BLOCKS];/* Pointers to blocks */,所以可以计算ext3文件系统的极限: 最大分区:     因为定义的是无符号32位数,所以可能定位的block范围为2^32,也就是4G,如果一个block

分布式海量数据系统Big Table架构分析

分布式海量数据系统Big Table架构分析 朱晓洁   潘维民 在信息爆炸的时代,解决PT级的海量数据存取管理服务问题背景下,由Google设计出分布式海量数据存储系统Big Table,基于Google 几个基础的架构:Google的分布式文件系统(GFS)存储日志,文件和数据文件;高可用的.序列化的分布式锁服务组件Chubby.本文从架构组件,算法以及性能等方面对BigTable进行一个宏观的概括分析,希望读者能借助本文对Big Table乃至NoSql有一个较为全面的认识. 分布式海量数

Thrift的TProtocol类体系原理及源码详解:类继承架构分析

这部分相关的类主要实现与协议相关的内容,这里说的协议是指对数据传输格式封装的协 议,实现不同的协议来适合不同场景下的数据传输,因为在不同的场景下不同协议对于数据 传输来说效率有很大的差别.下面是这个部分相关类的类关系图: 由以上类图可以发现所有的协议类都从TProtocol类直接或间接继承,每一个协议 类都有一个对应的生产对象工厂(协议工厂).TProtocol是一个抽象的类,不能直接使用的 ,它有一个直接子类默认实现了所有方法(空实现),如果我们需要定义自己的数据传输协 议可以直接从这个类继承