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 <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 >>> > > >
