Re: [Qemu-devel] [PATCH 2/2] virtio-blk: disable write cache if not negotiated

From: Kevin Wolf <kwolf@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: anthony@codemonkey.ws, rusty@rustcorp.com.au,
	qemu-devel@nongnu.org, kvm@vger.kernel.org, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/2] virtio-blk: disable write cache if not negotiated
Date: Wed, 04 Jul 2012 12:16:19 +0200	[thread overview]
Message-ID: <4FF417F3.2090400@redhat.com> (raw)
In-Reply-To: <4FF2F8DF.4020806@redhat.com>

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 <pbonzini@redhat.com>
>> 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