From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KoDBN-00006R-83
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 04:17:09 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KoDBL-00005c-Mb
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 04:17:08 -0400
Received: from [199.232.76.173] (port=45913 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KoDBL-00005V-Hb
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 04:17:07 -0400
Received: from mx20.gnu.org ([199.232.41.8]:19124)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <markmc@redhat.com>) id 1KoDBM-0003GP-5g
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 04:17:08 -0400
Received: from mx2.redhat.com ([66.187.237.31])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <markmc@redhat.com>) id 1KoDBJ-0003T1-Pc
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 04:17:06 -0400
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
From: Mark McLoughlin <markmc@redhat.com>
In-Reply-To: <48EF0A26.90209@redhat.com>
References: <48EE38B9.2050106@codemonkey.ws>  <48EF0A26.90209@redhat.com>
Content-Type: text/plain
Date: Fri, 10 Oct 2008 09:12:48 +0100
Message-Id: <1223626368.3618.26.camel@blaa>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Reply-To: Mark McLoughlin <markmc@redhat.com>, 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: Gerd Hoffmann <kraxel@redhat.com>
Cc: Chris Wright <chrisw@redhat.com>, kvm-devel <kvm-devel@lists.sourceforge.net>, Ryan Harper <ryanh@us.ibm.com>, qemu-devel@nongnu.org, Laurent Vivier <Laurent.Vivier@bull.net>

On Fri, 2008-10-10 at 09:54 +0200, Gerd Hoffmann wrote:
> Hi,
> 
> > Read performance should be unaffected by using O_DSYNC.  O_DIRECT will
> > significantly reduce read performance.  I think we should use O_DSYNC by
> > default and I have sent out a patch that contains that.  We will follow
> > up with benchmarks to demonstrate this.
> 
> 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.

Cheers,
Mark.