From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46408) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmMdK-0007NF-Fm for qemu-devel@nongnu.org; Wed, 04 Jul 2012 06:16:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmMdF-0007gy-Ko for qemu-devel@nongnu.org; Wed, 04 Jul 2012 06:16:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:29798) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmMdF-0007gj-CZ for qemu-devel@nongnu.org; Wed, 04 Jul 2012 06:16:25 -0400 Message-ID: <4FF417F3.2090400@redhat.com> Date: Wed, 04 Jul 2012 12:16:19 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1341321642-24598-1-git-send-email-pbonzini@redhat.com> <1341321642-24598-3-git-send-email-pbonzini@redhat.com> <4FF2F87C.6010600@redhat.com> <4FF2F8DF.4020806@redhat.com> In-Reply-To: <4FF2F8DF.4020806@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] virtio-blk: disable write cache if not negotiated List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: rusty@rustcorp.com.au, mst@redhat.com, qemu-devel@nongnu.org, anthony@codemonkey.ws, kvm@vger.kernel.org Am 03.07.2012 15:51, schrieb Paolo Bonzini: > Il 03/07/2012 15:49, Kevin Wolf ha scritto: >>> If the guest does not support flushes, we should run in writethrough mode. >>>> The setting is temporary until the next reset, so that for example the >>>> BIOS will run in writethrough mode while Linux will run with a writeback >>>> cache. >>>> >>>> VIRTIO_BLK_F_FLUSH has been introduced in Linux 2.6.32 (in 2009) and >>>> was backported to RHEL/CentOS 5.6 (in 2010). The Windows drivers have >>>> two bugs, which I reported on the Red Hat Bugzilla as bugs 837321 and >>>> 837324. With these patches they will suffer a performance hit but >>>> gain correctness. >>>> >>>> Signed-off-by: Paolo Bonzini >> I generally like the idea for a default, but doesn't this override even >> an explicit cache=writeback? > > Yes. It doesn't override cache=unsafe though. When the guest doesn't support flushes, cache=writeback is equivalent to cache=unsafe, so if you want the old behaviour back you can switch to cache=unsafe without additional risks. We don't have a cache=directunsafe, though, so if you want to get the old behaviour of cache=none back, you're out of luck. Not sure how acceptable this is. Irrespective of this concern I've come to the conclusion that I agree and we actually must enforce this for non-unsafe mode, and not doing it is a bug. Kevin