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

[Peter Lieven]

Am 18.07.2013 um 20:54 schrieb ronnie sahlberg <address@hidden>:

> BlockLimitsVPD  OptimalUnmapGranularity also applies to unmapping with
> writesame16 :
> 
> An OPTIMAL UNMAP GRANULARITY field set to a non-zero value indicates
> the optimal granularity in logical blocks
> for unmap requests (e.g., an UNMAP command or a WRITE SAME (16)
> command with the UNMAP bit set to
> one). An unmap request with a number of logical blocks that is not a
> multiple of this value may result in unmap
> operations on fewer LBAs than requested. An OPTIMAL UNMAP GRANULARITY
> field set to 0000_0000h indicates
> that the device server does not report an optimal unmap granularity.
> 
> So if you send a writesame16+unmap-bit  that honours the "optimal
> unmap request" you have a pretty good chance
> that the blocks will be unmapped. If they are not they will at least
> be overwritten as zero.

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 as well
as the write_zeroes_w_discard capability via the BDI 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
>>