作者简介:黄伟亮,毕业于苏州大学,曾在苏州博世汽车零部件有限公司汽车多媒体事业部工作。从事汽车多媒体娱乐系统平台开发六年多,接触Linux系统近10年。对Linux系统性能优化、开放内核、文件系统和存储设备、USB和虚拟化感兴趣。
开始
作者一直认为文件系统是建立在块设备上的数据库,文件名是检索数据库中数据的手段。原理总是很简单的,就像火箭需要有足够大的反推力装置,就像空调制冷通过汽化吸收热量的原理一样。但是实现起来比较复杂。
我很喜欢ext4文件系统。原因之一是我一直在处理这个文件系统。我已经一年多没有做过别的事情了,我的工作就是这些。另一个原因是,它是linux世界中使用最广泛的文件系统,谷歌的GFS也是建立在ext4之上的。此外,ext4的著名维护者也在谷歌工作,社区的维护者在回答问题时非常活跃和友好。但是,因为是偏好,所以不需要任何理由。
回顾作者当年的学习过程,简单总结一下,有表面的,也有深刻的。过程也充满艰辛。都说信息时代,网上有上千篇文章,但是看别人的文章,没有自己的经历深刻。
但是由于空间和精力的限制,本文没有分析文件系统的技术细节,比如jbd2在文件系统中的具体功能和分析,只提供了一个分析文件系统的实用流程。
然后,拿个SD卡跟着我。
Ext4布局
Ext4的布局细节这里略过,童鞋可以上本页了解:
https://ext 4 . wiki . kernel . org/index . PHP/ext 4 _ Disk _ Layout # Inline _ Data
一定要看完这篇傻逼文章!如果那个链接受不了,那就看下图:
mkfs.ext4命令格式化块设备后,块设备上ext4的布局大致如上图所述,包括以下信息:
块设备被按group 来划分,每个group有对应的group deorSuper block在Group 0中, 非group 0中的super block是backup super blockJournal block的位置并不是在最后一个group.(本例中,journal block在group 2)找到文件系统超级块超级块
首先,如果磁盘是DOS分区格式,使用fdisk命令检查磁盘的分区信息。从磁盘的分区信息中,我们可以得到以下内容:
整个磁盘有多大磁盘被分成了多少个分区每个分区的大小和起始结束的位置下图给出了一个例子,下面的文件系统分析也是基于这个磁盘:/dev/sde1。
下图清晰描述了用于测试的SD卡的分区信息。对于块设备/dev/sde,最小的单位是扇区,扇区大小通常为512。SD卡的大小可以用扇区来描述。
然后,我们要开始寻找ext4的超级块。ext4的超级块包含一个幻数:_ _ _ le 16s _ magic = 0xef 53,我们可以用它来确认超级块。
使用Linux的常见命令dd+hexdump查看您想要查看的块设备的任何位置的内容。
如下图所示,dd命令:
sudo DD if =/dev/SDE bs = 512 skip = 2048 | hex dump-C-n 2048
Skip转到块设备sde1的偏移量2048 x 512B(这里,512是扇区大小),hexdump给出其后面的2KB内容。在0x438处,找到了ext4的超级块幻字,同时在使用mkfs.ext4时,-L参数指定的diskLabel为“SDE 1 _韦勒”
定位日志块和索引节点表
Ext4没有jbd2还会活吗?当然可以!但是,会变得很不靠谱。jbd2和文件系统之间的关系将在以后的文章中详细描述。但是,我们需要知道日志块设备是一个通用日志层,它为其他文件系统提供日志服务。
由于文件的写入和挂载过程与jbd2密切相关,在分析文件系统问题时,我们通常需要查询日志块的内容进行分析,因此请按照以下内容定位日志块。
首先使用dumpe2fs查看sde1 block设备上ext4文件系统的信息,这是本文唯一使用的ext4原生工具。
如下图所示,可以知道以下信息:
journal的位置信息存储在inode table 的 offset 8 上(inode index = 8)journal的整个大小是16MBjournal的长度则是和文件系统的block size相同, 也是4KB.Inode size 是256B命令:
sudo dumpe2fs /dev/sde1
然后,问题来了。为了找到日志的起始位置,我们必须找到索引节点索引8的位置。其实用hexdump直接搜索journal的魔字也能找到Journal块的起始位置,不过这是我初学的时候的方法,现在想起来太低了。
定位索引节点表
回到sudo dumpe2fs /dev/sde1命令的输出结果,在组0的描述中,Inode表的起始块号是65。
众所周知,文件系统的块大小为4 KB,索引节点大小为256B .
那么索引节点表中索引节点索引8的偏移量是(8-1) x 256B = 0x700
使用以下命令转储从0x700开始截取256B的内容:
命令:
sudo DD if =/dev/SDE 1 bs = 4096 skip = 65 | hex dump-Cv-n 2048
因此,日志块的起始位置为0x00010000 x 4KB,即块号为0x10000、大小为0x1000 x 4KB(16MB)的块。
如何判断结果?以上结果如何才能准确?
journal块还定义了数据格式,判断依据是/dev/sde1设备的0x10000块偏移量处的数据内容应该是Journal超级块,块类型4表示Journal超级块v2。
窥见真相:
命令:
sudo DD if =/dev/SDE 1 bs = 4096 skip = 65536 | hex dump-Cv-n 2048
找到文件内容的位置
为了找到文件内容在磁盘上的位置,我们需要知道在ext4上创建文件的过程。数据块位图和索引节点位图像簿记员一样要记录数据块和索引节点表的使用情况。索引节点表用于描述文件内容所在的块数和块数。
首先,我们在数据块设备sde1挂载的目录中创建文件file1.txt,然后使用ls -i命令获取文件file1.txt的索引节点索引.
在以下示例中,file1.txt的索引节点索引为12。
inode表中inode12的偏移量为(12-1) x256B = 0xB00。使用以下命令转储索引节点表,并在0xB00位置截取256字节:
命令:
sudo DD if =/dev/SDE 1 bs = 4096 skip = 65 | hex dump-Cv-n 4096
从图中可以看出,文件的数据块位于0x00008021。我们出去看看吧。猜猜我在文件里写了什么。
命令:
sudo DD if =/dev/SDE 1 bs = 4096 skip = 32801 | hex dump-Cv-n 4096
找到文件名位置
不知道大家好奇不好奇,这个文件在根目录下,那么文件名在哪里呢?ext4如何知道它在一个文件夹中包含哪些文件?
首先,根目录也是一个目录,目录在文件系统中的表示和文件的表示是一样的。
您还可以找到根目录的索引节点索引
我们可以看到当前目录的索引节点索引,即“.”,是2。
索引节点索引2内容(该命令被忽略,您可以考虑该命令是什么样子的):
根据inode表描述,根目录的数据块在块偏移量0x25处,长度为一个块。
让我们看看块号为0x25的内容。我们可以看到文件名,如“.”,"..",lost+found和file1.txt至于这个块的数据格式定义,请自行学习。
命令:
sudo DD if =/dev/SDE 1 bs = 4096 skip = 37 | hex dump-Cv-n 4096
添加软链接后的文件系统分析
在测试目录下添加一个软链接文件,指向文件file1.txt
使用前面的方法查找softlink1的索引节点,这是一个链接文件。
软连接与普通文件和文件夹一样,由索引节点表描述:
我们可以看到,一个新的文件softlink1已经通过根目录中inode所指向的数据块通过上面部分中的相同方法添加了。在下图中,softlink1的描述如下:
0x0000000d 意为这个文件的inode index.0x09意为文件名字的长度0x07意为文件的类型是soft link.接下来,让我们看看转储索引节点索引0x0d上的文件内容:
0xa1ff中的0xa表示该文件是一个软链接类型的文件(详见inode数据格式定义)。对于这种类型的文件,ext4处理如下:
如果目标字符串长度小于60字节,符号链接的目标将存储在此字段中。否则,将使用范围或块映射来分配数据块以存储链接目标。
也就是说,如果目标文件名的大小为
删除文件后的文件系统分析
作为文件创建的反向操作,文件删除操作的基本原理是找到文件的inode,修改文件的inode,释放inode(空闲inode号)和数据块。
删除目录中的file1.txt文件后,我们分别转储被删除文件的inode内容、被删除文件的file内容和根目录的extent内容。
已删除文件的索引节点:扩展区的块数和块数变为0。删除时间由原来的0更改为0x5976f7a3(epoch格式),这意味着删除了inode,它不指向任何数据,从而化解了与原文件file1.txt的关系(如上图)。
文件内容仍然存在,但原始盘区占用的块已经释放:
根目录的范围内容没有更改:
也就是说,删除一个文件实际上是在操作对应文件的inode表。
结局
本文用DD、hexdump、dump2fs和ls四个命令完成了对ext4文件系统的简单分析练习。本文之所以简单,是因为它只包含了文件系统基本操作的分析实践,而以此类推。希望这篇论文能给大家带来一些帮助。同时,我也希望丹尼尔能指出本文的不足之处。先谢谢你。
另外,我没有用debugfs工具分析ext4的原因是为了让大家更直观的了解分析练习的过程。
1.《Ext4 ext4文件系统之裸数据的分析实践》援引自互联网,旨在传递更多网络信息知识,仅代表作者本人观点,与本网站无关,侵删请联系页脚下方联系方式。
2.《Ext4 ext4文件系统之裸数据的分析实践》仅供读者参考,本网站未对该内容进行证实,对其原创性、真实性、完整性、及时性不作任何保证。
3.文章转载时请保留本站内容来源地址,https://www.lu-xu.com/jiaoyu/1294303.html