From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KpZ8r-00062a-93
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 21:56:09 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KpZ8p-000626-Oq
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 21:56:08 -0400
Received: from [199.232.76.173] (port=55470 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KpZ8p-00061v-DP
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 21:56:07 -0400
Received: from mail2.shareable.org ([80.68.89.115]:41153)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1KpZ8p-0008Jh-2H
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 21:56:07 -0400
Date: Tue, 14 Oct 2008 02:56:04 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
Message-ID: <20081014015604.GA12895@shareable.org>
References: <48EE38B9.2050106@codemonkey.ws> <48F38C5E.1080504@redhat.com>
	<20081013182231.GA6369@shareable.org> <48F394C7.6050201@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <48F394C7.6050201@redhat.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Chris Wright <chrisw@redhat.com>, Mark McLoughlin <markmc@redhat.com>, Ryan Harper <ryanh@us.ibm.com>, kvm-devel <kvm-devel@lists.sourceforge.net>, Laurent Vivier <Laurent.Vivier@bull.net>

Rik van Riel wrote:
> >If there are multiple qemu/kvm guests accessing the same disk image in
> >a cluster, provided the host cluster filesystem uses a fully coherent
> >protocol, ordinary cached reads should be fine.  (E.g. not NFS).
> 
> The problem is when the synchronization only happens in the guests,
> which is a legitimate and common configuration.
> 
> Ie. the hosts just pass through the IO and the guests run a GFS
> cluster.

Ok, if you are using multiple hosts with a non-coherent host
filesystem for the virtual disk, or a non-coherent host block device
for the virtual disk, it won't work.

But why would you do that?

What is the legitimate and common configuration where you'd share a
virtual among multiple _hosts_ with a non-coherent host file/device
sharing protocol and expect it to work?

Do you envisage qemu/kvm using O_DIRECT over NFS or SMB on the host, or
something like that?

> Caching either reads or writes at the host level causes problems.

But only if the hosts are using a non-coherent protocol.  Not having a
visible effect (except timing) is pretty much the definition of
coherent caching.

Is there a reason why you wouldn't use, say, GFS on the host (because
it claims to be coherent)?  Does performance suck relative to O_DIRECT
over NFS?

-- Jamie