[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/3] qemu-img: Use zero writes after source back
From: |
Max Reitz |
Subject: |
Re: [Qemu-devel] [PATCH 2/3] qemu-img: Use zero writes after source backing EOF |
Date: |
Wed, 24 Apr 2019 15:42:41 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
On 18.04.19 20:59, Eric Blake wrote:
> On 7/13/18 6:14 AM, Max Reitz wrote:
>> Past the end of the source backing file, we memset() buf_old to zero, so
>> it is clearly easy to use blk_pwrite_zeroes() instead of blk_pwrite()
>> then.
>>
>> Signed-off-by: Max Reitz <address@hidden>
>> ---
>> qemu-img.c | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>
>> @@ -3458,8 +3461,12 @@ static int img_rebase(int argc, char **argv)
>> if (compare_buffers(buf_old + written, buf_new + written,
>> n - written, &pnum))
>> {
>> - ret = blk_pwrite(blk, offset + written,
>> - buf_old + written, pnum, 0);
>> + if (buf_old_is_zero) {
>> + ret = blk_pwrite_zeroes(blk, offset + written,
>> pnum, 0);
>
> Should we allow BDRV_REQ_MAY_UNMAP here, either unconditionally, or
> based on a command line knob that told us whether the user is more
> interested in a sparse result (that still reads as zero) vs. a
> fully-allocated result?
I wouldn’t trust that. We haven’t yet switched to the new backing file
at this point, so I think a driver would be correct in handling such
requests by punching a hole in the file -- which would lead to the new
backing file poking through once we’ve switched to it.
Max
> Reviewed-by: Eric Blake <address@hidden>
signature.asc
Description: OpenPGP digital signature