From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KoD6k-0006hS-Bq
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 04:12:22 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KoD6j-0006gj-25
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 04:12:21 -0400
Received: from [199.232.76.173] (port=41237 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KoD6i-0006gg-UK
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 04:12:20 -0400
Received: from mx20.gnu.org ([199.232.41.8]:18740)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <aurelien@aurel32.net>)
	id 1KoD6j-0002hc-PV
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 04:12:21 -0400
Received: from hall.aurel32.net ([88.191.82.174])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <aurelien@aurel32.net>) id 1KoD6e-00036Z-Iq
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 04:12:16 -0400
Date: Fri, 10 Oct 2008 10:11:57 +0200
From: Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
Message-ID: <20081010081157.GA13431@volta.aurel32.net>
References: <48EE38B9.2050106@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <48EE38B9.2050106@codemonkey.ws>
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>

On Thu, Oct 09, 2008 at 12:00:41PM -0500, Anthony Liguori wrote:

[snip]

> So to summarize, I think we should enable O_DSYNC by default to ensure  
> that guest data integrity is not dependent on the host OS, and that  
> practically speaking, cache=off is only useful for very specialized  
> circumstances.  Part of the patch I'll follow up with includes changes  
> to the man page to document all of this for users.
>
> Thoughts?
>

While I agree O_DSYNC should be the defaults, I wonder if we should keep
the current behaviour available for those who want it. We can imagine
the following options:
  cache=off	O_DIRECT
  cache=read	O_DSYNC		(default)
  cache=on	0

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net