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

From: ronnie sahlberg <ronniesahlberg@gmail.com>
To: Peter Lieven <pl@kamp.de>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert
Date: Thu, 18 Jul 2013 11:54:56 -0700	[thread overview]
Message-ID: <CAN05THSsNrVsx_X0F4F9CAxGxDgg9RSM4HGfxfiSMsZrZWsubg@mail.gmail.com> (raw)
In-Reply-To: <E531DAAC-C5F4-4574-9B66-80E06B7AC4C5@kamp.de>

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.

On Thu, Jul 18, 2013 at 11:43 AM, Peter Lieven <pl@kamp.de> wrote:
>
> Am 18.07.2013 um 16:35 schrieb Paolo Bonzini <pbonzini@redhat.com>:
>
>> 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
>