qemu-devel
[Top][All Lists]
Advanced

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

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert
Date: Fri, 19 Jul 2013 07:58:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7

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.

Paolo

> and than zero
> out the whole device with bdrv_write_zeroes and the BDRV_MAY_DISCARD
> flag.
> 
> the logic for this is already prepared in patch4 (topic of this email). 
> except that
> i have to exchange bdrv_discard with bdrv_write_zeroes w/ BDRV_MAY_DISCARD.
> 
> what do you think?
> 
> 
> 
>>
>>
>> On Thu, Jul 18, 2013 at 11:43 AM, Peter Lieven <address@hidden> wrote:
>>>
>>> Am 18.07.2013 um 16:35 schrieb Paolo Bonzini <address@hidden>:
>>>
>>>> Il 18/07/2013 16:32, Peter Lieven ha scritto:
>>>>>>>
>>>>>> (Mis)alignment and granularity can be handled later.  We can ignore them
>>>>>> for now.  Later, if we decide the best way to support them is a flag,
>>>>>> we'll add it.  Let's not put the cart before the horse.
>>>>>>
>>>>>> BTW, I expect alignment!=0 to be really, really rare.
>>>>> To explain my concerns:
>>>>>
>>>>> I know that my target has internal page size of 15MB. I will check what
>>>>> happens
>>>>> if I deallocate this 15MB in chunks of lets say 1MB. If the page gets
>>>>> unprovisioned
>>>>> after the last chunk is unmapped it would be fine :-)
>>>>
>>>> You're talking of granularity here, not (mis)alignment.
>>>
>>> you are right. for the target i am talking about this is 30720 512-byte 
>>> blocks for the granularity (pagesize) and 0 for the alignment.
>>> i will see what happens if I write same w/unmap the whole 30720 blocks in 
>>> smaller blocks ;-) otherwise i will have to add support for honoring this 
>>> values in qemu-img convert
>>> as a follow up.
>>>
>>> Peter
>>>
> 
> 
> 




reply via email to

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