From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KpZeN-0002hR-58
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 22:28:43 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KpZeK-0002hF-La
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 22:28:41 -0400
Received: from [199.232.76.173] (port=45081 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KpZeK-0002hC-Fp
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 22:28:40 -0400
Received: from anvil.nuitari.net ([67.205.71.108]:35654)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <nuitari-qemu@nuitari.net>) id 1KpZeK-0004sj-CB
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 22:28:40 -0400
Date: Mon, 13 Oct 2008 22:28:47 -0400 (EDT)
From: nuitari-qemu@nuitari.net
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
In-Reply-To: <20081014015604.GA12895@shareable.org>
Message-ID: <Pine.LNX.4.64.0810132220500.8862@anvil.nuitari.net>
References: <48EE38B9.2050106@codemonkey.ws> <48F38C5E.1080504@redhat.com>
	<20081013182231.GA6369@shareable.org> <48F394C7.6050201@redhat.com>
	<20081014015604.GA12895@shareable.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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>, Laurent Vivier <Laurent.Vivier@bull.net>, kvm-devel <kvm-devel@lists.sourceforge.net>

> 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?

Complexity?

To set up GFS2 you have to have a full cluster setup, get it working, make 
sure that locking works, that quorum is achieved, have failover and 
proper fencing working properly.

Plus you then have to maintain all of that.

Then you find out that GFS2 is not ready for production (deadlocks), GFS 
is too old to be supported by a recent kernel.

OCFS isn't easier either.