在运行 XFS 文件系统上的 KVM/qemu 的 CentOS 7.1.1503（3.10.0-229.el7.x86_64）系统上，我试图找出具体是什么在为 VM 磁盘映像文件添加额外的空间。
$ ls -ls --block-size=1k
15728648 -rw-------. 1 qemu qemu 15728640 Aug 8 07:50 original.img
15728640 -rw-------. 1 qemu qemu 15728640 Aug 8 08:25 original.imgcopied
2288960 -rw-------. 1 qemu qemu 15728640 Aug 8 09:36 original.imgsparsified
15728640 -rw-------. 1 qemu qemu 15728640 Aug 7 13:23 thickprov.img
0 -rw-------. 1 qemu qemu 15728640 Aug 7 13:28 thinprov.img
$ filefrag *
original.img: 1 extent found
original.imgcopied: 1 extent found
original.imgsparsified: 713 extents found
thickprov.img: 1 extent found
thinprov.img: 0 extents found
这是这些文件所在的文件系统：
# xfs_info /dev/mapper/centos_centsager-home
meta-data=/dev/mapper/centos_centsager-home isize=256 agcount=4, agsize=15968512 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0
data = bsize=4096 blocks=63874048, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal bsize=4096 blocks=31188, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
据我所知，原始 .img 文件显示文件系统上的实际大小比其显示大小大 8kb。我想更好地理解这一点。我在另一个盒子上的 ext4 文件系统上还有一个 50GB 的映像文件，显示其实际磁盘空间使用量比其显示大小大 92k。这两个文件都是通过 KVM/qemu/libvirt 进行厚配置的，并已在测试虚拟机中用于各种用途，但它们的内部文件系统从未接近满载。
列出的其他文件只是我进行一些测试的结果，目的是弄清楚发生了什么。这些报告的大小对我来说是有意义的。
15728640 15728640 original.imgcopied # 'cp' of original.img
2288960 15728640 original.imgsparsified # 'virt-sparsify' of original.img
15728640 15728640 thickprov.img # Fresh VM create with same parameters as original.img
0 15728640 thinprov.img # Same VM create but with a sparse allocation.
那么，原始 .img 文件中的额外 8k 是由于范围信息、文件碎片还是其他完全不同的原因？
谢谢。
答案1
当写入触发文件中新扩展区的分配时，XFS 有时会推测性地分配超出当前写入操作所需扩展区的额外扩展区。其想法是，未来的写入很可能会导致文件进一步增大，因此通过预先分配额外扩展区可以获得额外的性能。