预备文章,熟悉Ext2文件系统。看前面的blog 分析Ext2文件系统结构
问题:
如果一个4G的文件,删除开始几个字节,底层磁盘会发生什么变化?
猜想:
在团队的分享讨论中,有人认为会有高效的方式,优化文件修改。让我们用实验测试一下,ext2文件系统具体是怎么执行的。
实践:
1. 采用 linux loop设备作为虚拟磁盘,并mount到一个文件。 磁盘一共1000个block,每个block大小是512。(实践上创建完成之后,发现是500个block,每个block大小是1024,总容量没有变化。)
dd if=/dev/zero of=~/file.img bs=512 count=1000 LOOFDEV=`sudo losetup --find --show ~/file.img` mkdir file.image.loop -p sudo mkfs -t ext2 $LOOFDEV sudo mount $LOOFDEV file.image.loop
获取块大小
BLOCKSIZE=`dumpe2fs ~/file.img | grep "Block size:" | awk '{print $NF}'`
2. 查看文件系统详细信息
dumpe2fs ~/file.img
输入结果如下:
1 dumpe2fs 1.44.1 (24-Mar-2018) 2 Filesystem volume name: <none> 3 Last mounted on: <not available> 4 Filesystem UUID: 53664a8d-19e9-4cb3-9cd9-6c1c4f5f1598 5 Filesystem magic number: 0xEF53 6 Filesystem revision #: 1 (dynamic) 7 Filesystem features: ext_attr resize_inode dir_index filetype sparse_super large_file 8 Filesystem flags: signed_directory_hash 9 Default mount options: user_xattr acl 10 Filesystem state: not clean 11 Errors behavior: Continue 12 Filesystem OS type: Linux 13 Inode count: 64 14 Block count: 500 15 Reserved block count: 25 16 Free blocks: 472 17 Free inodes: 53 18 First block: 1 19 Block size: 1024 20 Fragment size: 1024 21 Reserved GDT blocks: 1 22 Blocks per group: 8192 23 Fragments per group: 8192 24 Inodes per group: 64 25 Inode blocks per group: 8 26 Filesystem created: Sun May 10 16:29:03 2020 27 Last mount time: Sun May 10 16:29:04 2020 28 Last write time: Sun May 10 16:29:04 2020 29 Mount count: 1 30 Maximum mount count: -1 31 Last checked: Sun May 10 16:29:03 2020 32 Check interval: 0 (<none>) 33 Reserved blocks uid: 0 (user root) 34 Reserved blocks gid: 0 (group root) 35 First inode: 11 36 Inode size: 128 37 Default directory hash: half_md4 38 Directory Hash Seed: 97e7d950-9ee2-405e-9dfa-f36c2ff7baa5 39 40 41 Group 0: (Blocks 1-499) 42 Primary superblock at 1, Group descriptors at 2-2 43 Reserved GDT blocks at 3-3 44 Block bitmap at 4 (+3) 45 Inode bitmap at 5 (+4) 46 Inode table at 6-13 (+5) 47 472 free blocks, 53 free inodes, 2 directories 48 Free blocks: 28-499 49 Free inodes: 12-64
14行显示,有500个块
16行显示,空闲块是472个。
19行显示,每个块大小是1024字节。
3. 创建一个文件,写入3个块(实际是4给块,最后一个块是EOF)
cd file.image.loop/ COUNT=$BLOCKSIZE python -c "print('a' * $COUNT + 'b' * $COUNT + 'c' * $COUNT)" |sudo tee a.txt
写入1024个字母“a”(HEX 61,DEX97 )
写入10024个字母“b”(HEX 62,DEX98 )
写入10024个字母“b”(HEX 63,DEX99 )
4. 查看文件字节数
ls查看
ls -l a.txt -rw-r--r-- 1 root root 3073 5月 10 16:42 a.txt
wc点字节数
cat a.txt |wc -c 3073
5. 查看文件的具体信息
sudo debugfs $LOOFDEV <<< "stat a.txt"
输出如下结果:
Inode: 12 Type: regular Mode: 0644 Flags: 0x0 Generation: 2365015721 Version: 0x00000001 User: 0 Group: 0 Size: 3073 File ACL: 0 Links: 1 Blockcount: 8 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x5eb7be5a -- Sun May 10 16:42:02 2020 atime: 0x5eb7bea6 -- Sun May 10 16:43:18 2020 mtime: 0x5eb7be5a -- Sun May 10 16:42:02 2020 BLOCKS: (0-3):28-31 TOTAL: 4
数据位于28-31的磁盘块中。
获取起始块和长度
BNUM=`sudo debugfs $LOOFDEV <<< "blocks a.txt" |grep -o "^[0-9 ]*" |cut -d " " -f1` BLEN=`sudo debugfs $LOOFDEV <<< "blocks a.txt" |grep -o "^[0-9 ]*" |wc -w`
6. 查看文件对应的block内容
sudo dd if=$LOOFDEV bs=$BLOCKSIZE count=$BLEN skip=$BNUM | od -t x1 -Ax
输入如下内容
4+0 records in 4+0 records out 4096 bytes (4.1 kB, 4.0 KiB) copied, 8.578e-05 s, 47.8 MB/s 000000 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 * 000400 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62 * 000800 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 * 000c00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000c10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 001000
删除四个字符
sudo sed -i -r '1s/.{4}//' a.txt cat a.txt |wc -c
再次查看文件内容
sudo dd if=$LOOFDEV bs=$BLOCKSIZE count=$BLEN skip=$BNUM | od -t x1 -Ax
没有发生变化,同步数据到磁盘也没有发生变化
sync -f a.txt
这是因为文件的inode和block发生了变化,但是原来存储数据的block并没有擦除。这就是为什么一些磁盘恢复工具能恢复数据的原理。
7. 重新查看文件的具体信息
sudo debugfs $LOOFDEV <<< "stat a.txt"
显示结果如下:
Inode: 13 Type: regular Mode: 0644 Flags: 0x0 Generation: 1601438359 Version: 0x00000001 User: 0 Group: 0 Size: 3069 File ACL: 0 Links: 1 Blockcount: 6 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x5eb7c5b5 -- Sun May 10 17:13:25 2020 atime: 0x5eb7c5b8 -- Sun May 10 17:13:28 2020 mtime: 0x5eb7c5b5 -- Sun May 10 17:13:25 2020 BLOCKS: (0-2):32-34 TOTAL: 3
我们可以看到block,从前面的28-21移动到了32-34
8. 再次获取新的数据块起始和长度
注意,实际中,数据块不一定是连续的,本实验是因为采用了一个全新的空磁盘。或者再做一次实验,就会发现数据块,可能不连续了。
BNUM=`sudo debugfs $LOOFDEV <<< "blocks a.txt" |grep -o "^[0-9 ]*" |cut -d " " -f1` BLEN=`sudo debugfs $LOOFDEV <<< "blocks a.txt" |grep -o "^[0-9 ]*" |wc -w`
查看文件对应的block内容
sudo dd if=$LOOFDEV bs=$BLOCKSIZE count=$BLEN skip=$BNUM | od -t x1 -Ax
内容如下,已发生变化
3+0 records in 3+0 records out 3072 bytes (3.1 kB, 3.0 KiB) copied, 0.000226374 s, 13.6 MB/s 000000 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 * 0003f0 61 61 61 61 61 61 61 61 61 61 61 61 62 62 62 62 000400 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62 * 0007f0 62 62 62 62 62 62 62 62 62 62 62 62 63 63 63 63 000800 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 * 000bf0 63 63 63 63 63 63 63 63 63 63 63 63 0a 00 00 00 000c00
9. 清理环境
首先查看还有没有进程打开该磁盘,有的话,kill该进程
sudo lsof $LOOFDEV
cd .. sudo umount $LOOFDEV sudo losetup -d $LOOFDEV rm file.img -rf rm file.image.loop -rf
结论:
整个磁盘都会移动,这其实是最好的方式, 所有数据都是循序读写。
修改一个文件,其实就是创建了一个新文件,inode和磁盘数据都会发生变化。
这是由于文件系统,只提供了read和write的操作,并没有提供插入和删除的操作,其实是应用程序实现了新建文件的操作。
我们可以实现sed过程的strace
1 sudo strace sed -i -r '1s/.{4}//' a.txt 2 execve("/bin/sed", ["sed", "-i", "-r", "1s/.{4}//", "a.txt"], 0x7ffcf1b4cfe0 /* 24 vars */) = 0 3 brk(NULL) = 0x564cef104000 4 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) 5 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) 6 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 7 fstat(3, {st_mode=S_IFREG|0644, st_size=167308, ...}) = 0 8 mmap(NULL, 167308, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9820a7a000 9 close(3) = 0 10 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) 11 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libselinux.so.1", O_RDONLY|O_CLOEXEC) = 3 12 read(3, "177ELF211 3 >