Re: [Qemu-devel] [RFC PATCH] block: optimize zero writes with bdrv_write_zeroes

[Kevin Wolf <kwolf@redhat.com>]

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