On 24.04.20 14:54, 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-cluster.c | 2 +- > block/qcow2.c | 34 ++++++++++++++++++++++++++++++++++ > 2 files changed, 35 insertions(+), 1 deletion(-)
[...]
> diff --git a/block/qcow2.c b/block/qcow2.c
> index 9cfbdfc939..98065d7808 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
[...]
> @@ -4214,6 +4215,39 @@ static int coroutine_fn
> qcow2_co_truncate(BlockDriverState *bs, int64_t offset,
[...]
> + /* Write explicit zeros for the unaligned head */
> + if (zero_start > old_length) {
> + uint64_t len = zero_start - old_length;
> + uint8_t *buf = qemu_blockalign0(bs, len);
I wonder whether I should raise the question of why this should be
block-aligned when we make no effort to align the offset its written to
(and we know it isn’t aligned to qcow2 clusters at least).
I probably should not.
Reviewed-by: Max Reitz <mre...@redhat.com>
> + QEMUIOVector qiov;
> + qemu_iovec_init_buf(&qiov, buf, len);
> +
> + qemu_co_mutex_unlock(&s->lock);
> + ret = qcow2_co_pwritev_part(bs, old_length, len, &qiov, 0, 0);
> + qemu_co_mutex_lock(&s->lock);
> +
> + qemu_vfree(buf);
> + if (ret < 0) {
> + error_setg_errno(errp, -ret, "Failed to zero out the new
> area");
> + goto fail;
> + }
> + }
signature.asc
Description: OpenPGP digital signature
