On Wed, Mar 06, 2013 at 07:06:24PM +0100, Paolo Bonzini wrote: > Il 06/03/2013 18:50, Peter Lieven ha scritto: > >> > Commit 9a665b2b made bdrv_truncate() call bdrv_drain_all(), but this > >> > breaks > >> > QCOW images, as well other future image formats (such as VHDX) that may > >> > call > >> > bdrv_truncate(bs->file) from within a read/write operation. For > >> > example, QCOW > >> > will cause an assert, due to tracked_requests not being empty (since the > >> > read/write that called bdrv_truncate() is still in progress). > > I'm not sure such bdrv_truncate calls are necessary. QCOW2 doesn't have > them (almost; there is one in qcow2_write_compressed, I'm not even sure > that one is necessary though), and I think QCOW's breaks using it with a > block device as a backing file. > > Paolo
QCOW breaks with it using a normal raw posix file as a device. As a test: qemu-img create -f qcow test.qcow 5G. Now run qemu with that drive mounted, and try to partition and format it. QEMU now asserts. The nicety of being able to using truncate during a write call, especially for VHDX (which can have relatively large block/cluster sizes), so to grow the file sparsely in a dynamically allocated file.