Re: [Qemu-devel] [RFC] Propose the Fast Virtual Disk (FVD) image format that outperforms QCOW2 by 249%

[Chunqiang Tang]

> It's something filesystems have to deal with.  Real storage is getting
> increasingly virtualized.  While this didn't matter for the real high
> end storage which has been doing this for a long time it's getting more
> and more exposed to the filesystem.  That includes LVM layouts and
> thinly provisioned disk arrays, which are getting increasingly popular.
> That doesn't matter the 64k (or until recently 4k) cluster size in qcow2
> is a good idea, we'd want at least a magnitude or two larger extents
> to perform well, but it means filesystems really do have to cope with
> it.

Yes, a fundamental and optimal solution would be changing guest file 
systems, but it would take a much much longer route to introduce 
virtualization awareness into all guest file systems and its also requires 
changing the interface between the guest and the host.

> I/O into fully preallocated files uses exactly the same codepath as
> doing I/O to the block device, except for a identify logical to physical
> block mapping in the block device and a non-trivial one in the
> filesysgem.  Note that the block mapping is cached and does not affect
> the performance.  I've published the numbers for qemu in the various
> caching modes and all major filesystems a while ago, so I'm not making
> this up.

Preallocation is not a universal solution here, because it just defeats 
the other goal: thin provisioning. Moreover, if preallocation is used, it 
works best for RAW images and makes it unnecessary to use a compact image, 
which is exactly one goal of FVD, i.e., allowing optionally disabling a 
compact image data layout without giving up other features, e.g., 
copy-on-write.