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 <p...@kamp.de> wrote: > > Am 18.07.2013 um 16:35 schrieb Paolo Bonzini <pbonz...@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 >