From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S876r-0007zS-Pr for qemu-devel@nongnu.org; Thu, 15 Mar 2012 05:36:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S876l-0003Zr-MK for qemu-devel@nongnu.org; Thu, 15 Mar 2012 05:36:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S876l-0003Zk-EM for qemu-devel@nongnu.org; Thu, 15 Mar 2012 05:36:31 -0400 Message-ID: <4F61B817.2010702@redhat.com> Date: Thu, 15 Mar 2012 10:36:23 +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> In-Reply-To: <1331772155.24052.849.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 15/03/2012 01:42, Richard Laager ha scritto: >> > It is worse in that we do not want the hardware parameters exposed to the >> > guest to change behind the scenes, except if you change the machine type >> > or if you use the default unversioned type. > You're saying that discard_granularity and discard_zeros_data need to be > properties of the machine type? If you start with that as a requirement, > I can see why you want to always report discard_granularity=512 & > discard_zeros_data=1. But that design has many downsides. I'm not > convinced that discard_granularity and discard_zeros_data need to be > properties of the machine type. Why do you feel that's necessary? What's > the harm in those properties changing across QEMU startups (i.e. guest > boots)? 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. Paolo