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-11-02 23:53:31

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

使用hexdump工具追踪EXT4文件系统中的一个文件

昨天追踪EXT4文件系统的过程中出了点问题,就是找不到文件,于是试了一下追踪FAT32文件系统的,成功之后有了点信心,今天继续嗑EXT4文件系统,终于找到啦,记录一下. 操作系统:linux(centos 6.5) 文件系统:EXT4 工具:hexdump,windows自带计算器 参考书目:<数据重现-文件系统原理精解与数据恢复最佳实践>(马林 著),题为<Ext4文件系统架构分析>的系列博客,不知道原作是谁了. EXT4文件系统架构: 补充说明:EXT4文件系统中只有0号块组的

Ext4文件系统的特性和功能简介

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

Android架构分析之Android消息处理机制(三)

作者:刘昊昱 博客:http://blog.csdn.net/liuhaoyutz Android版本:4.4.2 本文我们来分析AndroidUI线程即主线程是怎样实现对消息的处理的. UI线程的实现类定义在frameworks/base/core/java/android/app/ActivityThread.java文件中.我们来看Android对ActivityThread类的说明 : 130/** 131 * This manages the execution of the main

ext4文件系统的delalloc选项造成单次写延迟增加的分析

最近我们的服务进程遇到kill -15后处于Z的状态,变为了僵尸进程,经过/proc/{thread_id}/stack查看其上线程的栈,发现是卡在了fwrite的过程中,而我们的系统中所有文件系统挂载参数都使用了delalloc参数,怀疑是这个原因:ext4挂载的时候打开了delalloc选项,然后系统在没有分配磁盘块的情况下写写写,到page cache被回写到磁盘时,发现磁盘已经满了,没办法分配新的磁盘块了,就Hang住了. 这篇文章是淘宝内核组的刘峥同学在内部技术论坛上发表的一篇文章,但

刨根问底:ext3/ext4文件系统最大空间及单个文件大小演算法则

从ext3和ext4文件系统来窥探空间和文件大小的演算法则 学习操作系统就不得不研究磁盘以及磁盘文件系统,磁盘是底层物理设备,而文件系统则是管理磁盘的上层工具,文件系统规划了磁盘存放数据的格式,确定了一个操作系统能够支持多大的磁盘空间,每个分区能够支持多大的数据空间,以及每个文件所能支持的大小.通常对系统管理员而言,最需要的知道的就是最大磁盘空间,最大分区空间以及最大文件的大小.本论题只讨论这三种大小到底是怎么算出来的,而不是死记硬背.知道了原理,以后不管遇到什么文件系统,都会有章可循,至少知道

秒杀系统架构分析与实战

0 系列目录 秒杀系统架构 秒杀系统架构分析与实战 1 秒杀业务分析 正常电子商务流程 (1)查询商品:(2)创建订单:(3)扣减库存:(4)更新订单:(5)付款:(6)卖家发货 秒杀业务的特性 (1)低廉价格:(2)大幅推广:(3)瞬时售空:(4)一般是定时上架:(5)时间短.瞬时并发量高: 2 秒杀技术挑战 假设某网站秒杀活动只推出一件商品,预计会吸引1万人参加活动,也就说最大并发请求数是10000,秒杀系统需要面对的技术挑战有: 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动,

秒杀系统架构分析与实战(参考、转载)

目录[-] 0 系列目录 1 秒杀业务分析 2 秒杀技术挑战 3 秒杀架构原则 4 秒杀架构设计 4.1 前端层设计 4.2 站点层设计 4.3 服务层设计 4.4 数据库设计 4.4.1 基本概念 4.4.2 设计思路 5 大并发带来的挑战 5.1 请求接口的合理设计 5.2 高并发的挑战:一定要“快” 5.3 重启与过载保护 6 作弊的手段:进攻与防守 6.1 同一个账号,一次性发出多个请求 6.2 多个账号,一次性发送多个请求 6.3 多个账号,不同IP发送不同请求 7 高并发下的数据安全