Am 24.02.2014 um 13:10 hat Paolo Bonzini geschrieben: > Il 24/02/2014 13:07, Kevin Wolf ha scritto: > >>> Yeah, that's why I wrote "or should be". Those are the intended > >>> semantics of bdrv_co_write_zeroes without BDRV_REQ_MAY_UNMAP: always > >>> allocate a cluster that will read as zeroes (allocating even if it > >>> does not necessarily write the zeroes). > >Which would mean that there is no way to say "give me zeroes, and do it > >in the cheapest way possible". Because that would be to leave the > >allocation status as it is and just toggle the zero bit. > > If bdrv_co_write_zeroes is SCSI's "WRITE SAME without UNMAP", then > it must allocate. I think "give me zeroes and do it in the cheapest > way possible" is BDRV_REQ_MAY_UNMAP (which *may* unmap but it > doesn't have to).
Hm, okay. So the intended behaviour for qcow2 is: - without MAY_UNMAP: Preallocate the cluster and set the zero flag so that its content isn't valid - with MAY_UNMAP: If the cluster is allocated, leave it allocated and set the zero flag; if it isn't, leave it unallocated and set the zero flag. > That said, the really expensive part of unmapping is probably > re-allocating the clusters on subsequent writes. The unmap itself > isn't that expensive (even if you have to flush the refcount blocks > before the L2 tables), is it? Flushes are pretty expensive. If you only have many discards in a row and then many allocations in a row, it's probably okay. Mixing them so that every other write is a discard might well kill performance. Kevin