Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert

[ronnie sahlberg]

On Fri, Jul 19, 2013 at 6:49 AM, Peter Lieven <address@hidden> wrote:
> On 19.07.2013 15:25, ronnie sahlberg wrote:
>>
>> On Thu, Jul 18, 2013 at 11:08 PM, Peter Lieven <address@hidden> wrote:
>>>
>>> On 19.07.2013 07:58, Paolo Bonzini wrote:
>>>>
>>>> Il 18/07/2013 21:28, Peter Lieven ha scritto:
>>>>>
>>>>> thanks for the details. I think to have optimal performance and best
>>>>> change for unmapping in qemu-img convert
>>>>> it might be best to export the OPTIMAL UNMAP GRANULARITY
>>>>
>>>> Agreed about this.
>>>>
>>>>> as well as the write_zeroes_w_discard capability via the BDI
>>>>
>>>> But why this?!?  It is _not_ needed.  All you need is to change the
>>>> default of the "-S" option to be the OPTIMAL UNMAP GRANULARITY if it is
>>>> nonzero.
>>>
>>> 2 reasons:
>>> a) Does this guarantee that the requests are aligned to multiple of the
>>> -S
>>> value?
>>>
>>> b) If I this flag exists qemu-img convert can do the "zeroing" a priori.
>>> This
>>> has the benefit that combined with bdrv_get_block_status requests before
>>> it
>>> might
>>> not need to touch large areas of the volume. Speaking for iSCSI its
>>> likely
>>> that
>>> the user sets a fresh volume as the destination, but its not guaranteed.
>>> With the Patch 4 there are only done a few get_block_status requests to
>>> verify
>>> this. If we just write zeroes with BDRV_MAY_UNMAP, we send hundreds or
>>> thousands of writesame requests for possibly already unmapped data.
>>>
>>> To give an example. If I take my storage with an 1TB volume. It takes
>>> about
>>> 10-12
>>> get_block_status requests to verify that it is completely unmapped. After
>>> this
>>> I am safe to set has_zero_init = 1 in qemu-img convert.
>>>
>>> If I would convert a 1TB image to this target where lets say 50% are at
>>> leat
>>> 15MB
>>> zero blocks (15MB is the OUG of my storage) it would take ~35000 write
>>> same
>>> requests to achieve the same.
>>
>> I am not sure I am reading this right, but you dont have to writesame
>> exactly 1xOUG to get it to unmap.
>> nxOUG will work too,
>> So instead of sending one writesame for each OUG range, you can send
>> one writesame for every ~10G or so.
>> Say 10G is ~667 OUGs for your case, so you can send
>> writesame for ~667xOUG in each command and then it would "only" take
>> ~100 writesames instead of ~35000.
>>
>> So as long as you are sending in multiples of OUG you should be fine.
>
> do I not have to take care of max_ws_size?

Yes you need to handle mas_ws_size   but I would imagine that on most
targets that max_ws_size >> OUG
I would be surprised if a target would set max_ws_size to just a single OUG.


>
> Peter