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内核中已经消失。

可以在两个地方找到扩展属性:一是在一个inode项结尾到下一个inode项开头的地方;二是inode.i_file_acl指向 的数据块之中,到3.0为止,这个数据块中不包含指向第二个扩展属性数据块的指针。理论上可以将每个属性值存储到一个单独的数据块中,但是3.0内核为止仍然没有这样做。

当扩展属性不存储在一个inode之后的时候,就会有一个头部ext4_xattr_ibody_header

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

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

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

日志布局

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

1.21.2  数据块头部

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

1.21.3  超级块

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

1.21.4  描述数据块Descriptor Block

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

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

1.21.5  数据块Data Block

存放的是通过日志写到磁盘的数据块。但是如果数据块的前4 bytes与jbd2的魔数匹配,那么这些4 bytes用0代替,并且在Descriptor Block中设置escaped。

 

时间: 2024-10-11 16:53:52

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

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

   接着上一篇博文,继续分析Ext4磁盘布局中的元数据. 1.7 超级块 超级块记录整个文件系统的大量信息,如数据块个数.inode个数.支持的特性.管理信息,等待. 如果设置sparse_super特性标志,超级块和块组描述符表的冗余备份仅存放在编号为0或3.5.7的幂次方的块组中.如果未设置sparse_super特性标志,冗余备份存在与所有的块组中.以下是2.6.32.18内核中对Ext4超级块的描述:   3.0的内核中,Ext4的超级块加入了以下相关元数据:快照.文件系统错误处理相关

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

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

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

Nexus S中的Android将使用ext4文件系统

Google 新发布的 Nexus S 智能手机将是 Android 设备第一个使用 Ext4 文件系统的手机.ext4(第四扩展文件系统)文件系统是Linux系统下的日志文件系统,是ext3文件系统的后继版本. Ext4 可以提供更佳的性能和可靠性,还有更为丰富的功能: 1. 与 Ext3 兼容. 执行若干条命令,就能从 Ext3 在线迁移到 Ext4,而无须重新格式化磁盘或重新安装系统.原有 Ext3 数据结构照样保留,Ext4 作用于新数据,当然,整个文件系统因此也就获得了 Ext4 所支

CentOS中EXT4文件系统是什么?CentOS中EXT4有什么用

Linux kernel 自 2.6.28 开始正式支持新的文件系统 Ext4. Ext4 是 Ext3 的改进版,修改了 Ext3 中部分重要的数据结构,而不仅仅像 Ext3 对 Ext2 那样,只是增加了一个日志功能而已.Ext4 可以提供更佳的性能和可靠性,还有更为丰富的功能: 1. 与 Ext3 兼容.执行若干条命令,就能从 Ext3 在线迁移到 Ext4,而无须重新格式化磁盘或重新安装系统.原有 Ext3 数据结构照样保留,Ext4 作用于新数据,当然,整个文件系统因此也就获得了 Ex

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

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

六大主流大数据采集平台架构分析

文章讲的是六大主流大数据采集平台架构分析,我们简单讨论了几种流行的数据收集平台,它们大都提供高可靠和高扩展的数据收集.大多平台都抽象出了输入,输出和中间的缓冲的架构.利用分布式的网络连接,大多数平台都能实现一定程度的扩展性和高可靠性. 随着大数据越来越被重视,数据采集的挑战变的尤为突出.今天为大家介绍几款数据采集平台: Apache Flume Fluentd Logstash Chukwa Scribe Splunk Forwarder 大数据平台与数据采集 任何完整的大数据平台,一般包括以下

android. mvc,mvp,mvvm架构分析

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

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

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