From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NoZQh-0007a0-62 for qemu-devel@nongnu.org; Mon, 08 Mar 2010 04:39:15 -0500 Received: from [199.232.76.173] (port=57046 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NoZQf-0007YZ-Mk for qemu-devel@nongnu.org; Mon, 08 Mar 2010 04:39:13 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NoZQe-0003hi-Ax for qemu-devel@nongnu.org; Mon, 08 Mar 2010 04:39:13 -0500 Received: from verein.lst.de ([213.95.11.210]:54492) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1NoZQd-0003hG-Sa for qemu-devel@nongnu.org; Mon, 08 Mar 2010 04:39:12 -0500 Date: Mon, 8 Mar 2010 10:39:08 +0100 From: Christoph Hellwig Subject: Re: [Qemu-devel] bs->enable_write_cache and the guest ABI Message-ID: <20100308093908.GA1914@lst.de> References: <4B93BB4A.8090605@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B93BB4A.8090605@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel , Christoph Hellwig On Sun, Mar 07, 2010 at 04:42:18PM +0200, Avi Kivity wrote: > This means that if I start a guest with cache=writethrough and then > restart (or live migrate) it with cache=none, then the guest will see a > change, even though the user only changed the drive's backing, not > something guest visible. In the case of live migration, the guest will > not even notice the change and we may be at risk of data loss. > > For 0.13 I propose setting enable_write_cache to true unconditionally. > For 0.12 the question is more difficult, since we'll be changing the > guest ABI. Given that guests are unlikely not to be able to cope with > write caches, and that the alternative is data loss, I believe that's > also the right solution there. Setting it to true unconditionally will cause performance degradation for cache=writethrough devices, as we now have to drain the queue in the guest for no reason at all. I think the better option would be to move the cache setting to qdev property on the block device at it's a device visible setting.