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

[Peter Lieven <pl@kamp.de>]

On 19.07.2013 16:00, ronnie sahlberg wrote:
> On Fri, Jul 19, 2013 at 6:49 AM, Peter Lieven <pl@kamp.de> wrote:
>> On 19.07.2013 15:25, ronnie sahlberg wrote:
>>> On Thu, Jul 18, 2013 at 11:08 PM, Peter Lieven <pl@kamp.de> 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.
for may target it is ;-(

maybe I would use max_ws_size for the write_zeroes_with unmap
thing. I would think it is a multiple of oug if it is specified.

Peter