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 <mre...@redhat.com>
>> ---
>> 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 <ebl...@redhat.com>
signature.asc
Description: OpenPGP digital signature
