From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8TYM-0005kL-Iq for qemu-devel@nongnu.org; Fri, 16 Mar 2012 05:34:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8TXz-0002ob-FZ for qemu-devel@nongnu.org; Fri, 16 Mar 2012 05:34:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8TXz-0002oD-7G for qemu-devel@nongnu.org; Fri, 16 Mar 2012 05:34:07 -0400 Message-ID: <4F63090A.60205@redhat.com> Date: Fri, 16 Mar 2012 10:34:02 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1331226917-6658-1-git-send-email-pbonzini@redhat.com> <1331226917-6658-7-git-send-email-pbonzini@redhat.com> <4F5A31B2.3050701@redhat.com> <4F5A46A1.4000508@redhat.com> <1331402560.8577.46.camel@watermelon.coderich.net> <4F5DEBCE.3040409@redhat.com> <1331665990.24052.42.camel@watermelon.coderich.net> <4F604B98.9090606@redhat.com> <1331772155.24052.849.camel@watermelon.coderich.net> <4F61B817.2010702@redhat.com> <1331858824.3076.20.camel@watermelon.coderich.net> In-Reply-To: <1331858824.3076.20.camel@watermelon.coderich.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 06/17] block: use bdrv_{co, aio}_discard for write_zeroes operations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Laager Cc: qemu-devel@nongnu.org Il 16/03/2012 01:47, Richard Laager ha scritto: > On Thu, 2012-03-15 at 10:36 +0100, Paolo Bonzini wrote: >> Changing across guest boots is a minor problem, but changing across >> migration must be avoided at all costs. >> >> BTW, after this discussion I think we can instead report >> discard_granularity = 512 and discard_zeroes_data=0 and get most of the >> benefit, at least on file-backed storage. > > Are you going to report that to guests all the time, or only when the > host supports discard? If you don't report it all the time, you could > still be "changing across migration". If you do report it all the time, > then you're incurring a performance penalty on systems that don't > support discard, as the guest will be sending discard requests that QEMU > has to throw away (but by which time some work has been wasted). I don't think that should be that bad. Discard requests should be relatively rare. > And either way, what you're proposing means that users with > discard_zeros_data = 1 hosts can't get the (albeit small) benefits of > that because some other QEMU user might want to do a migration across > heterogeneous storage. Yes, discard_zeroes_data can be made configurable on top, and either rejected or emulated if the storage does not support it. > Finally, I see your proposal of advertising fixed discard support It does not really have to be fixed, it's just a default. Paolo