Am 18.07.2013 um 20:54 schrieb ronnie sahlberg <ronniesahlb...@gmail.com>:
> 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 <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 >>