我刚刚发现什么稀疏文件是并且想对它们进行一些实验。在 wiki 上,您可以了解到这些文件很容易变得碎片化。我想检查一下情况有多糟糕。我通过以下方式创建了一个文件:
# truncate -s 10G sparse-file
# mkfs.ext4 -m 0 -L sparse ./sparse-file
我挂载的是稀疏文件,里面放了一个600M的文件。碎片级别如下所示:
# filefrag -v "/media/Grafi/sparse-file"
Filesystem type is: ef53
File size of /media/Grafi/sparse-file is 10737418240 (2621440 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 1032: 36864.. 37896: 1033:
1: 1043.. 1043: 37907.. 37907: 1:
2: 1059.. 1059: 37923.. 37923: 1:
3: 9251.. 9256: 46115.. 46120: 6:
4: 32768.. 32770: 51200.. 51202: 3: 69632:
5: 34816.. 55295: 77824.. 98303: 20480: 53248:
6: 55296.. 57343: 114688.. 116735: 2048: 98304:
7: 57344.. 69631: 120832.. 133119: 12288: 116736:
8: 69632.. 81919: 102400.. 114687: 12288: 133120:
9: 81920.. 98303: 135168.. 151551: 16384: 114688:
10: 98304.. 98306: 57344.. 57346: 3: 151552:
11: 100352.. 112639: 151552.. 163839: 12288: 59392:
12: 112640.. 145407: 165888.. 198655: 32768: 163840:
13: 145408.. 163839: 198656.. 217087: 18432:
14: 163840.. 163842: 40960.. 40962: 3: 217088:
15: 165888.. 178175: 217088.. 229375: 12288: 43008:
16: 178176.. 202751: 231424.. 255999: 24576: 229376:
17: 202752.. 206847: 258048.. 262143: 4096: 256000:
18: 206848.. 216756: 276480.. 286388: 9909: 262144:
19: 229376.. 229378: 43008.. 43010: 3: 299008:
20: 294912.. 294914: 53248.. 53250: 3: 108544:
21: 524288.. 524288: 55296.. 55296: 1: 282624:
22: 819200.. 819202: 61440.. 61442: 3: 350208:
23: 884736.. 884738: 63488.. 63490: 3: 126976:
24: 1048576.. 1048577: 67584.. 67585: 2: 227328:
25: 1081344.. 1081391: 69632.. 69679: 48: 100352:
26: 1572864.. 1572864: 71680.. 71680: 1: 561152:
27: 1605632.. 1605634: 73728.. 73730: 3: 104448:
28: 2097152.. 2097152: 75776.. 75776: 1: 565248:
29: 2097167.. 2097167: 75791.. 75791: 1: last
/media/Grafi/sparse-file: 25 extents found
我认为这是因为“稀疏”功能,但看起来所有包含其他文件系统的文件都以这种方式变得碎片化。看一下下面的例子:
创建一个全是零的文件:
# dd if=/dev/zero of=./zero bs=1M count=2048
检查其碎片级别:
# filefrag -v /media/Grafi/zero
Filesystem type is: ef53
File size of /media/Grafi/zero is 2147483648 (524288 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 32767: 6172672.. 6205439: 32768:
1: 32768.. 65535: 6205440.. 6238207: 32768:
2: 65536.. 98303: 6238208.. 6270975: 32768:
3: 98304.. 118783: 6270976.. 6291455: 20480:
4: 118784.. 151551: 6324224.. 6356991: 32768: 6291456:
5: 151552.. 184319: 6356992.. 6389759: 32768:
6: 184320.. 217087: 6389760.. 6422527: 32768:
7: 217088.. 249855: 6422528.. 6455295: 32768:
8: 249856.. 282623: 6455296.. 6488063: 32768:
9: 282624.. 315391: 6488064.. 6520831: 32768:
10: 315392.. 348159: 6520832.. 6553599: 32768:
11: 348160.. 380927: 6553600.. 6586367: 32768:
12: 380928.. 413695: 6586368.. 6619135: 32768:
13: 413696.. 446463: 6619136.. 6651903: 32768:
14: 446464.. 479231: 6651904.. 6684671: 32768:
15: 479232.. 511999: 6684672.. 6717439: 32768:
16: 512000.. 524287: 6717440.. 6729727: 12288: last,eof
/media/Grafi/zero: 2 extents found
所以基本上,这个文件有 17 个范围,但是从人类的角度来看,该文件有两个块
现在在此文件中创建一个文件系统:
# mkfs.ext4 -m 0 -L ext /media/Grafi/zero
再次检查其碎片:
# filefrag -v /media/Grafi/zero
Filesystem type is: ef53
File size of /media/Grafi/zero is 2147483648 (524288 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 257: 5505024.. 5505281: 258:
1: 265.. 265: 5505289.. 5505289: 1:
2: 272.. 273: 5505296.. 5505297: 2:
3: 289.. 289: 5505313.. 5505313: 1:
4: 8481.. 8486: 5507361.. 5507366: 6: 5513505:
5: 32768.. 32769: 5509120.. 5509121: 2: 5531648:
6: 98304.. 98305: 5511168.. 5511169: 2: 5574656:
7: 163840.. 163841: 5513216.. 5513217: 2: 5576704:
8: 229376.. 229377: 5515264.. 5515265: 2: 5578752:
9: 262144.. 262144: 5517312.. 5517312: 1: 5548032:
10: 294912.. 294913: 5519360.. 5519361: 2: 5550080: last
/media/Grafi/zero: 8 extents found
有谁知道这里到底发生了什么?为什么在其上创建文件系统后文件会变得碎片化?发生了什么length
?
添加:
该mkfs.ext4
参数-Enodiscard
不起作用。通过此选项,我可以看到文件的结构filefrag
(归零块)。但以这种方式创建文件系统后,无论如何,文件都会由于某种原因变得碎片化。也许是因为写入了文件系统元数据,并且它对归零的文件做了一些操作。我不知道。但是当我观察 的输出时filefrag
,我可以看到总是有 +6 个范围(在 2G 文件的情况下)。也许是因为超级块及其 5 个副本?但这仍然不能解释为什么整个文件是碎片化的——它仍然是同一个文件。
还有一件事。当我在此文件中重新创建文件系统时:
# mkfs.ext4 -Enodiscard /media/Grafi/zero
mke2fs 1.43 (17-May-2016)
/media/Grafi/zero contains a ext4 file system
created on Thu Jun 2 13:02:28 2016
Proceed anyway? (y,n) y
Creating filesystem with 524288 4k blocks and 131072 inodes
Filesystem UUID: 6d58dddc-439b-4175-9af6-8628f0d2a278
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
添加的范围神奇地消失了。
答案1
这看起来像是一个错误,mke2fs
导致它在清零 inode 表中的空间时使用它fallocate(fd, PUNCH_HOLE, ...)
而不是使用它(即使在使用时)。fallocate(fd, DISCARD_ZERO, ...)
-E nodiscard
在本地验证了此行为后,我向上游邮件列表提交了错误报告[email protected]
,并在一小时内获得了补丁,主题:
e2fprogs: block zero/discard cleanups
它们应该包含在 e2fsprogs-1.45 版本中,并且可能1.44.x 维护版本。如果您希望它们出现在供应商e2fsprogs
版本中,我建议您修补+构建您的 e2fsprogs 以验证这是否适合您,报告成功以便linux-ext4
补丁更快落地,然后向您选择的发行版提交错误报告,以便他们将上游补丁拉入其版本中。
答案2
$ /sbin/mkfs.ext4 test1
mke2fs 1.42.12 (29-Aug-2014)
Discarding device blocks: done
[...]
现在有提示了。我们看看说明书上是怎么说的:
-E extended-options
discard
Attempt to discard blocks at mkfs time (discarding blocks initially is useful
on solid state devices and sparse / thin-provisioned storage). When the device
advertises that discard also zeroes data (any subsequent read after the discard
and before write returns zero), then mark all not-yet-zeroed inode tables as
zeroed. This significantly speeds up filesystem initialization. This is set as
default.
因此,基本上,mkfs 知道底层存储上的旧数据不再重要,因此可以将其丢弃,并且底层存储可能有更好的方法来做到这一点,而不是仅仅用零覆盖。有了它,这里的文件系统就可以忘记数据块。
之后,mkfs 以某种随机访问模式构建它所需的任何文件系统结构,从而分配新的数据块。文件再次变得稀疏,并且存在一些碎片。
结果-Enodiscard
也许就是你所期望的:
$ /sbin/mkfs.ext4 -Enodiscard test2
$ /usr/sbin/filefrag test2
test2: 2 extents found