On 23.04.20 15:25, Kevin Wolf wrote: > Am 23.04.2020 um 12:53 hat Max Reitz geschrieben: >> 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. > > If we really want, I guess we could make full preallocation first try > passing BDRV_REQ_ZERO_WRITE to the protocol layer and if that succeeds, > we could skip setting the zero cluster flag at the qcow2 level.
That might be nice. > Feels like a separate patch, though. Definitely, yes. Max
signature.asc
Description: OpenPGP digital signature