如何恢复 Linux 上删除的文件-原理及普通文件的恢复（2）
|
- UID
- 1066743
|
如何恢复 Linux 上删除的文件-原理及普通文件的恢复（2）
数据块寻址方式回想一下，ext2_inode 结构的 i_block 域是一个大小为 EXT2_N_BLOCKS 的数组，其中保存的就是真正存放文件数据的数据块的位置。通常来说，EXT2_N_BLOCKS 大小为 15。在 ext2 文件系统，采用了直接寻址和间接寻址两种方式来对数据块进行寻址，原理如图3 所示：
图 3. 数据块寻址方式 - 对于 i_block 的前 12 个元素（i_block[0]到i_block[11]）来说，其中存放的就是实际的数据块号，即对应于文件的 0 到 11 块。这种方式称为直接寻址。
- 对于第13个元素（i_block[12]）来说，其中存放的是另外一个数据块的逻辑块号；这个块中并不存放真正的数据，而是存放真正保存数据的数据块的块号。即 i_block[12] 指向一个二级数组，其每个元素都是对应数据块的逻辑块号。由于每个块号需要使用 4 个字节表示，因此这种寻址方式可以访问的对应文件的块号范围为 12 到 (块大小/4)+11。这种寻址方式称为间接寻址。
- 对于第14个元素（i_block[13]）来说，其中存放也是另外一个数据块的逻辑块号。与间接寻址方式不同的是，i_block[13] 所指向的是一个数据块的逻辑块号的二级数组，而这个二级数组的每个元素又都指向一个三级数组，三级数组的每个元素都是对应数据块的逻辑块号。这种寻址方式称为二次间接寻址，对应文件块号的寻址范围为 (块大小/4)+12 到 (块大小/4)2+(块大小/4)+11。
- 对于第15个元素（i_block[14]）来说，则利用了三级间接索引，其第四级数组中存放的才是逻辑块号对应的文件块号，其寻址范围从 (块大小/4)2+(块大小/4)+12 到 (块大小/4)3+ (块大小/4)2+(块大小/4)+11。
ext2 文件系统可以支持1024、2048和4096字节三种大小的块，对应的寻址能力如下表所示：
表 1. 各种数据块对应的文件寻址范围块大小直接寻址间接寻址二次间接寻址三次间接寻址102412KB268KB64.26MB16.06GB204824KB1.02MB513.02MB265.5GB409648KB4.04MB4GB~ 4TB
掌握上面介绍的知识之后，我们就可以开始恢复文件的实验了。
准备文件系统为了防止破坏已有系统，本文将采用一个新的分区进行恢复删除文件的实验。
首先让我们准备好一个新的分区，并在上面创建 ext2 格式的文件系统。下面的命令可以帮助创建一个 20GB 的分区：
清单 5. 新建磁盘分区1
2
3
4
5
6
7
8
| # fdisk /dev/sdb << END
n
+20G
p
w
q
END
|
在笔者的机器上，这个分区是 /dev/sdb6。然后创建文件系统：
清单 6. 在新分区上创建 ext2 文件系统
并将其挂载到系统上来：
清单 7. 挂载创建的 ext2 文件系统1
2
| # mkdir /tmp/test
# mount /dev/sdb6 /tmp/test
|
在真正使用这个文件系统之前，让我们首先使用系统提供的一个命令 dumpe2fs 来熟悉一下这个文件系统的一些具体参数：
清单 8. 使用 dumpe2fs 熟悉这个文件系统的参数1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
| # dumpe2fs /dev/sdb6
dumpe2fs 1.39 (29-May-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: d8b10aa9-c065-4aa5-ab6f-96a9bcda52ce
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype sparse_super large_file
Default mount options: (none)
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 2443200
Block count: 4885760
Reserved block count: 244288
Free blocks: 4797829
Free inodes: 2443189
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1022
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16288
Inode blocks per group: 509
Filesystem created: Mon Oct 29 20:04:16 2007
Last mount time: Mon Oct 29 20:06:52 2007
Last write time: Mon Oct 29 20:08:31 2007
Mount count: 1
Maximum mount count: 39
Last checked: Mon Oct 29 20:04:16 2007
Check interval: 15552000 (6 months)
Next check after: Sat Apr 26 20:04:16 2008
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Default directory hash: tea
Directory Hash Seed: d1432419-2def-4762-954a-1a26fef9d5e8
Group 0: (Blocks 0-32767)
Primary superblock at 0, Group descriptors at 1-2
Reserved GDT blocks at 3-1024
Block bitmap at 1025 (+1025), Inode bitmap at 1026 (+1026)
Inode table at 1027-1535 (+1027)
31224 free blocks, 16276 free inodes, 2 directories
Free blocks: 1543-22535, 22537-32767
Free inodes: 12, 14-16288
...
Group 149: (Blocks 4882432-4885759)
Block bitmap at 4882432 (+0), Inode bitmap at 4882433 (+1)
Inode table at 4882434-4882942 (+2)
2817 free blocks, 16288 free inodes, 0 directories
Free blocks: 4882943-4885759
Free inodes: 2426913-2443200
|
应用前面介绍的一些知识，我们可以看到，这个文件系统中，块大小（Block size）为4096字节，因此每个块组中的块数应该是4096*8=32768个（Blocks per group），每个块组的大小是 128MB，整个分区被划分成20GB/(4KB*32768)=160个。但是为什么我们只看到 150 个块组（0到149）呢？实际上，在 fdisk 中，我们虽然输入要创建的分区大小为 20GB，但实际上，真正分配的空间并不是严格的20GB，而是只有大约 20*109 个字节，准确地说，应该是 (4885760 * 4096) / (1024*1024*1024) = 18.64GB。这是由于不同程序的计数单位的不同造成的，在使用存储设备时经常遇到这种问题。因此，这个分区被划分成 150 个块组，前 149 个块组分别包含 32768 个块（即 128B），最后一个块组只包含 3328 个块。
另外，我们还可以看出，每个索引节点的大小是 128 字节，每个块组中包含 16288 个索引节点，在磁盘上使用 509 个块来存储（16288*128/4096），在第一个块组中，索引节点表保存在 1027 到 1535 块上。
数据块和索引节点是否空闲，是分别使用块位图和索引节点位图来标识的，在第一个块组中，块位图和索引节点位图分别保存在 1025 和 1026 块上。
dumpe2fs 的输出结果中还包含了其他一些信息，我们暂时先不用详细关心这些信息。 |
|
|
|
|
|
