From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KpA5L-0005ur-5Z
	for qemu-devel@nongnu.org; Sun, 12 Oct 2008 19:10:51 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KpA5J-0005uf-CN
	for qemu-devel@nongnu.org; Sun, 12 Oct 2008 19:10:49 -0400
Received: from [199.232.76.173] (port=50858 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KpA5J-0005uc-A5
	for qemu-devel@nongnu.org; Sun, 12 Oct 2008 19:10:49 -0400
Received: from mail2.shareable.org ([80.68.89.115]:54361)
	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 1KpA5J-0002cl-7Z
	for qemu-devel@nongnu.org; Sun, 12 Oct 2008 19:10:49 -0400
Date: Mon, 13 Oct 2008 00:10:42 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
Message-ID: <20081012231042.GB22509@shareable.org>
References: <48EE38B9.2050106@codemonkey.ws> <48EF0A26.90209@redhat.com>
	<1223626368.3618.26.camel@blaa>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1223626368.3618.26.camel@blaa>
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: Mark McLoughlin <markmc@redhat.com>, qemu-devel@nongnu.org
Cc: Chris Wright <chrisw@redhat.com>, kvm-devel <kvm-devel@lists.sourceforge.net>, Ryan Harper <ryanh@us.ibm.com>, Gerd Hoffmann <kraxel@redhat.com>, Laurent Vivier <Laurent.Vivier@bull.net>

Mark McLoughlin wrote:
> > So O_SYNC on/off is pretty much equivalent to disk write caching being
> > on/off, right?  So we could make that guest-controlled, i.e. toggeling
> > write caching in the guest (using hdparm) toggles O_SYNC in qemu?
> 
> I don't think it's correct to equate disk write caching to completing
> guest writes when the data has been copied to the host's page cache. The
> host's page cache will cache much more data for much longer than a
> typical disk, right?
> 
> If so, then this form of write caching is much more likely to result in
> fs corruption if the host crashes. In that case, all qemu users would
> really need to disable write caching in the guest using hdparm, which
> they don't need to do on bare-metal.

However, should the effect of the guest turning off the IDE disk write
cache perhaps be identical to the guest issuing IDE cache flush commands
following every IDE write?

This could mean the host calling fdatasync, or fsync, or using
O_DSYNC, or O_DIRECT - whatever the host does for IDE flush cache.

What this means _exactly_ for data integrity is outside of qemu's
control and is a user & host configuration issue.  But qemu could
provide consistency at least.

-- Jamie