From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V03i5-000340-2s for qemu-devel@nongnu.org; Fri, 19 Jul 2013 01:58:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V03i3-0004lG-Rb for qemu-devel@nongnu.org; Fri, 19 Jul 2013 01:58:33 -0400 Received: from mail-qa0-x233.google.com ([2607:f8b0:400d:c00::233]:65155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V03i3-0004lA-Mg for qemu-devel@nongnu.org; Fri, 19 Jul 2013 01:58:31 -0400 Received: by mail-qa0-f51.google.com with SMTP id f11so2151570qae.10 for ; Thu, 18 Jul 2013 22:58:31 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51E8D573.8030509@redhat.com> Date: Fri, 19 Jul 2013 07:58:11 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1373885375-13601-5-git-send-email-pl@kamp.de> <51E66ACD.70706@redhat.com> <20130717102551.GF2458@dhcp-200-207.str.redhat.com> <51E6C5FC.1030304@redhat.com> <7C1EEB41-E2B3-4186-9188-379F02E76FF9@kamp.de> <51E6CE81.6000400@redhat.com> <36C25446-54C7-4D1F-9D8D-E8A3991489BD@kamp.de> <20130718092316.GG3582@dhcp-200-207.str.redhat.com> <51E7C260.50404@redhat.com> <51E7C707.7010101@kamp.de> <51E7C9C4.5010202@redhat.com> <51E7CBC8.1010804@kamp.de> <51E7E035.3010702@redhat.com> <51E7EDD0.6050001@kamp.de> <51E7F332.9020607@redhat.com> <51E7F715.3020706@kamp.de> <51E7F9CB.7050304@redhat.com> <51E7FC87.1040207@kamp.de> <51E7FD2E.5070900@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel , ronnie sahlberg 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 wrote: >>> >>> Am 18.07.2013 um 16:35 schrieb Paolo Bonzini : >>> >>>> 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 >>> > > >