On a CentOS 7.1.1503 (3.10.0-229.el7.x86_64) system running KVM/qemu on an XFS filesystem, I'm attempting to work out what specifically is adding additional space to a VM diskimage file.

$ 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

This is the filesystem these files reside on:

# 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

From what I have been able to understand, the original.img file is showing the actual size on the filesystem is 8kb larger than the apparent size. I'd like to get a better understanding of this. I also have a 50GB image file on an ext4 filesystem on another box that is showing its actual disk space use is 92k larger than its apparent size. Both of these files were thick provisioned via KVM/qemu/libvirt and have been used in test VMs for various things, but their internal filesystems were never close to full.

The other files listed are just the result of some testing I was doing to get my head wrapped around what is happening. These reported sizes make sense to me.

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.

So, is the extra 8k in the original.img file due to extent information, file fragmentation, or something else entirely?


  • you need to look what is an sparse file.
    – c4f4t0r
    Commented Aug 8, 2015 at 14:19
  • Yep I understand how sparse files are allocated with empty blocks and that the 'cp' command without extra switches will fill in those null blocks and the actual file size will match the allocated size. I'm not understanding the extra 8k in the actual file size of the original.img file though. On another image file I have that is 50GB the actual file size is 92k larger. So I'm trying to understand where those extra blocks are coming from.
    – Chrisxb
    Commented Aug 8, 2015 at 19:39
  • There may be a connection with this question on unix.SE. Maybe you can bring any insight there?
    – xhienne
    Commented Dec 16, 2016 at 16:51

1 Answer 1


When a write triggers allocation of a new extent in a file, XFS will sometimes speculatively allocate extra extents beyond those required for the current write operation. The idea is that future writes may well cause the file to grow further, so by pre-emptively allocating extra extents extra performance can be gained.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .