From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KoH4K-0005L6-BH
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 08:26:08 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KoH4J-0005KA-3j
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 08:26:07 -0400
Received: from [199.232.76.173] (port=55239 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KoH4I-0005K3-Q7
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 08:26:06 -0400
Received: from yw-out-1718.google.com ([74.125.46.152]:23604)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1KoH4I-0001Dr-H4
	for qemu-devel@nongnu.org; Fri, 10 Oct 2008 08:26:06 -0400
Received: by yw-out-1718.google.com with SMTP id 6so153547ywa.82
	for <qemu-devel@nongnu.org>; Fri, 10 Oct 2008 05:26:04 -0700 (PDT)
Message-ID: <48EF49D8.3090002@codemonkey.ws>
Date: Fri, 10 Oct 2008 07:26:00 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
References: <48EE38B9.2050106@codemonkey.ws>
	<20081010081157.GA13431@volta.aurel32.net>
In-Reply-To: <20081010081157.GA13431@volta.aurel32.net>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
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>

Aurelien Jarno wrote:
> 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)
>   

Or maybe cache=off, cache=on, cache=wb.  So that the default was 
cache=on which is write-through, or the user can choose write-back caching.

But that said, I'm concerned that this is far too confusing for users.  
I don't think anyone is relying on disk write performance when in 
write-back mode simply because the guest already has a page cache so 
writes are already being completed instantaneously from the 
application's perspective.


Regards,

Anthony Liguori
>   cache=on	0
>
>