qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/4] block: Trivial fixes in offloading code


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH 0/4] block: Trivial fixes in offloading code
Date: Wed, 4 Jul 2018 16:09:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 2018-07-03 03:26, Fam Zheng wrote:
> On Mon, 07/02 14:35, Max Reitz wrote:
>> On 2018-07-02 04:58, Fam Zheng wrote:
>>> These are the low priority ones spotted by Kevin and Max last week.
>>>
>>> Fam Zheng (4):
>>>   qcow2: Drop unused cluster_data
>>>   file-posix: Fix fd_open check in raw_co_copy_range_to
>>>   qcow2: Drop unreachable break
>>>   raw: Drop superfluous semicolon
>>>
>>>  block/file-posix.c | 2 +-
>>>  block/qcow2.c      | 3 ---
>>>  block/raw-format.c | 2 +-
>>>  3 files changed, 2 insertions(+), 5 deletions(-)
>>
>> Thanks, applied to my block branch:
>>
>> https://git.xanclic.moe/XanClic/qemu/commits/branch/block
>>
>>
>> Do you want to make qcow2_co_copy_range_to() do something special on
>> BDRV_REQ_ZERO_WRITE?  To me, it seems natural, but on the other hand
>> maybe it wouldn't bring anything.  If the protocol layer supports copy
>> offloading, then it'll probably do that zero write efficiently anyway.
>> If it doesn't, qemu-img convert will just fall back to the usual
>> implementation which involves writing zeroes when zeroes are read, so...
>>  What's your opinion?
> 
> In bdrv_co_copy_range_internal() there is
> 
>     if (flags & BDRV_REQ_ZERO_WRITE) {
>         return bdrv_co_pwrite_zeroes(dst, dst_offset, bytes, flags);
>     }
> 
> before calling driver .bdrv_co_copy_range_to() callback. I think this is 
> enough?

Ah, right...  Yep, that's enough. :-)

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]