On 03/08/2012 07:15 PM, Paolo Bonzini wrote: > While the formats/protocols are free to implement a discard operation > that does *not* zero the data, providing a common view to the guests is > the only way to avoid configuration and migration nightmares. (We don't > want the admin to manually set up discard_zeroes_data/discard_granularity!) > > This has a couple of drawbacks: > > 1) QEMU effectively will not try to use discard unless discard_zeroes_data > is true. To do this we could add a flag such as BDRV_ALWAYS_DISCARD, > which the device models could use if their discard_zeroes_data property is > set to false. However, I haven't done this, estimating that no strictly > positive integer could represent the number of people using it. > > 2) it may turn a thin-provisioning operation into a full preallocation, > which is not nice. > > 3) it may cost memory for a bounce buffer that only needs to be filled > with zeroes. > > While (3) can be worked around, the only way around the other two, > unfortunately, is support in the formats and protocols. We will still > provide device options to opt out of this, but with raw and qed covered > (+ qcow2 without backing file, and qcow3 in the future) it should not > be too bad.
Can't qcow2 with a backing file also be supported? Zero out the first cluster, and remember it. The following discards can reuse this zero cluster, as long as it hasn't been overwritten. -- error compiling committee.c: too many arguments to function
