本文仅理论探讨,真实数据恢复,敬请先参考:
《Linux ext4 rm 误删,用extundelete恢复失败/报错,无数血泪教训!!!附:ext4误删后的正确处理步骤》
https://blog.csdn.net/weixin_42745590/article/details/86418144
1扇区(sector)=512字节(byte)
1数据块(block)=8扇区=4KB(mkfs时指定,默认4KB,可设置为1KB - 64KB)
Ext4字段使用little-endian顺序写入磁盘;但journal日志使用big-endian顺序写入磁盘。
superblock记录文件系统的各种信息,例如block总数,inode总数,支持的功能,维护信息等。如果sparse_super置位,则superblock和组描述符的副本仅保留在Group编号为0或3、5、7……的Group中。如果未设置该标志,superblock在所有组中均有副本。
Magic signature=0x53EF,位于偏移0x38,即56字节处。UUID位于偏移0x68:
即Block Group Descriptor,描述本group的inode信息、datablock信息
当block=1kb时,BGD起始于block2
当block>1kb时,BGD起始于block1
本案例中为block=1kb,则BGD起始了block2
Inodetable位于BGD偏移0x8处,:
Inode字段定义:
如果文件<=12个block,inode中可以直接存储其所有block指针。
如果文件的block数据在13个block 至【 ($block_size / 4) ^ 3 + ($block_size / 4) ^ 2 + ($block_size / 4) + 12】个block之间,则需要借助多级索引来存储所有数据块。本案例block=1kb,三线索引inode可存储16777216+65536+268=16843020byte,大概16MB文件。
inode中有15个指针数组,其中12个是直接索引,后面三个分别是一级索引、二级索引和三级索引。如下图示:
如果文件大于16MB,则需要inode开启扩展属性i_extra_isize,使用Extent Tree,本文不再展开。
Group0的inode table处数值为0x0124,即block292,即 292*2=584扇区:
如上图,文件Inode为14
Group0 inode table起始于block 292,
而inode14位于(14-1)*128=1664 byte = 0x680 byte .
Inode偏移60byte=0x3C byte处,记录了文件的数据块索引,下图为0x000029b7:
第0x000029b7=10679个数据块,位于:10679*1024byte/512byte=21358扇区,下图显示为文件的真实内容:
Ext4引入 “Extents”概念,可参考《Linux ext4文件系统原理(二)-大文件Extent结构解析及数据恢复实例-rm误删恢复》
温馨提示:如重要数据丢失,还请在行动前咨询专业工程师建议,以免数据遭到二次破坏。
直接技术支持:shop396558956.taobao.com
官方网站:http://www.data-unit.com/