On 22.04.20 17:21, Kevin Wolf wrote: > If BDRV_REQ_ZERO_WRITE is set and we're extending the image, calling > qcow2_cluster_zeroize() with flags=0 does the right thing: It doesn't > undo any previous preallocation, but just adds the zero flag to all > relevant L2 entries. If an external data file is in use, a write_zeroes > request to the data file is made instead. > > Signed-off-by: Kevin Wolf <kw...@redhat.com> > --- > block/qcow2.c | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > > diff --git a/block/qcow2.c b/block/qcow2.c > index 9cfbdfc939..bd632405d1 100644 > --- a/block/qcow2.c > +++ b/block/qcow2.c
[...] > @@ -4214,6 +4215,35 @@ static int coroutine_fn > qcow2_co_truncate(BlockDriverState *bs, int64_t offset, > g_assert_not_reached(); > } > > + if ((flags & BDRV_REQ_ZERO_WRITE) && offset > old_length) { > + uint64_t zero_start = QEMU_ALIGN_UP(old_length, s->cluster_size); > + uint64_t zero_end = QEMU_ALIGN_UP(offset, s->cluster_size); > + > + /* Use zero clusters as much as we can */ > + ret = qcow2_cluster_zeroize(bs, zero_start, zero_end - zero_start, > 0); It’s kind of a pity that this changes the cluster mappings that were established when using falloc/full preallocation already (i.e., they become preallocated zero clusters then, so when writing to them, we need COW again). But falloc/full preallocation do not guarantee that the new data is zero, so I suppose this is the only thing we can reasonably do. I personally don’t really care about whether zero_end is aligned or not, so either way: Reviewed-by: Max Reitz <mre...@redhat.com>
signature.asc
Description: OpenPGP digital signature