> 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.
