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

简介: 接着上一篇博文,继续分析Ext4磁盘布局中的元数据。 1.7 超级块 超级块记录整个文件系统的大量信息,如数据块个数、inode个数、支持的特性、管理信息,等待。 如果设置sparse_super特性标志,超级块和块组描述符表的冗余备份仅存放在编号为0或3、5、7的幂次方的块组中。

   接着上一篇博文,继续分析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记录目录项。
  

 

相关文章
|
2月前
|
安全 数据处理 数据安全/隐私保护
C/S架构与B/S架构的适用场景分析
C/S架构(客户端/服务器架构)与B/S架构(浏览器/服务器架构)在适用场景上各有特点,主要取决于应用的具体需求、用户群体、系统维护成本、跨平台需求等因素。
144 6
|
17天前
|
存储 SQL 分布式计算
湖仓一体架构深度解析:构建企业级数据管理与分析的新基石
【10月更文挑战第7天】湖仓一体架构深度解析:构建企业级数据管理与分析的新基石
22 1
|
2月前
|
存储 监控 安全
SaaS业务架构:业务能力分析
【9月更文挑战第20天】在数字化时代,软件即服务(SaaS)模式逐渐成为企业软件解决方案的首选。SaaS 业务架构设计对于提供高效、可靠的服务至关重要。其核心业务能力包括:用户管理(注册登录、角色权限)、数据管理(存储备份、安全共享)、业务流程管理(设计定制、工作流自动化)、应用集成(第三方应用、移动应用)及客户服务(支持培训、反馈改进)。通过优化这些能力,可为企业提供更高效、可靠的 SaaS 服务。
48 11
|
3月前
|
消息中间件 负载均衡 Kafka
Kafka 实现负载均衡与故障转移:深入分析 Kafka 的架构特点与实践
【8月更文挑战第24天】Apache Kafka是一款专为实时数据处理和流传输设计的高性能消息系统。其核心设计注重高吞吐量、低延迟与可扩展性,并具备出色的容错能力。Kafka采用分布式日志概念,通过数据分区及副本机制确保数据可靠性和持久性。系统包含Producer(消息生产者)、Consumer(消息消费者)和Broker(消息服务器)三大组件。Kafka利用独特的分区机制实现负载均衡,每个Topic可以被划分为多个分区,每个分区可以被复制到多个Broker上,确保数据的高可用性和可靠性。
59 2
|
2月前
|
缓存 负载均衡 数据管理
深入探索微服务架构的核心要素与实践策略在当今软件开发领域,微服务架构以其独特的优势和灵活性,已成为众多企业和开发者的首选。本文将深入探讨微服务架构的核心要素,包括服务拆分、通信机制、数据管理等,并结合实际案例分析其在不同场景下的应用策略,旨在为读者提供一套全面、深入的微服务架构实践指南。**
**微服务架构作为软件开发领域的热门话题,正引领着一场技术革新。本文从微服务架构的核心要素出发,详细阐述了服务拆分的原则与方法、通信机制的选择与优化、数据管理的策略与挑战等内容。同时,结合具体案例,分析了微服务架构在不同场景下的应用策略,为读者提供了实用的指导和建议。
|
3月前
|
数据采集 存储 Java
Flume Agent 的内部原理分析:深入探讨 Flume 的架构与实现机制
【8月更文挑战第24天】Apache Flume是一款专为大规模日志数据的收集、聚合及传输而设计的分布式、可靠且高可用系统。本文深入解析Flume Agent的核心机制并提供实际配置与使用示例。Flume Agent由三大组件构成:Source(数据源)、Channel(数据缓存)与Sink(数据目的地)。工作流程包括数据采集、暂存及传输。通过示例配置文件和Java代码片段展示了如何设置这些组件以实现日志数据的有效管理。Flume的强大功能与灵活性使其成为大数据处理及实时数据分析领域的优选工具。
94 1
|
3月前
|
消息中间件 存储 大数据
大数据-数据仓库-实时数仓架构分析
大数据-数据仓库-实时数仓架构分析
118 1
|
3月前
|
前端开发 大数据 数据库
🔥大数据洪流下的决战:JSF 表格组件如何做到毫秒级响应?揭秘背后的性能魔法!💪
【8月更文挑战第31天】在 Web 应用中,表格组件常用于展示和操作数据,但在大数据量下性能会成瓶颈。本文介绍在 JavaServer Faces(JSF)中优化表格组件的方法,包括数据处理、分页及懒加载等技术。通过后端分页或懒加载按需加载数据,减少不必要的数据加载和优化数据库查询,并利用缓存机制减少数据库访问次数,从而提高表格组件的响应速度和整体性能。掌握这些最佳实践对开发高性能 JSF 应用至关重要。
63 0
|
3月前
|
存储 设计模式 运维
Angular遇上Azure Functions:探索无服务器架构下的开发实践——从在线投票系统案例深入分析前端与后端的协同工作
【8月更文挑战第31天】在现代软件开发中,无服务器架构因可扩展性和成本效益而备受青睐。本文通过构建一个在线投票应用,介绍如何结合Angular前端框架与Azure Functions后端服务,快速搭建高效、可扩展的应用系统。Angular提供响应式编程和组件化能力,适合构建动态用户界面;Azure Functions则简化了后端逻辑处理与数据存储。通过具体示例代码,详细展示了从设置Azure Functions到整合Angular前端的全过程,帮助开发者轻松上手无服务器应用开发。
25 0
|
4月前
|
供应链 负载均衡 数据库
软件架构一致性问题之分析代码修改的 Scalability如何解决
软件架构一致性问题之分析代码修改的 Scalability如何解决
53 1

热门文章

最新文章