From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KpSO1-0000aA-3b
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 14:43:21 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KpSNz-0000Xu-Fi
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 14:43:20 -0400
Received: from [199.232.76.173] (port=50750 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KpSNz-0000Xg-AG
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 14:43:19 -0400
Received: from yx-out-1718.google.com ([74.125.44.158]:16946)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1KpSNy-0007QU-Sz
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 14:43:19 -0400
Received: by yx-out-1718.google.com with SMTP id 3so390671yxi.82
	for <qemu-devel@nongnu.org>; Mon, 13 Oct 2008 11:43:18 -0700 (PDT)
Message-ID: <48F396C2.30704@codemonkey.ws>
Date: Mon, 13 Oct 2008 13:43:14 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <48EE38B9.2050106@codemonkey.ws>
	<20081013170610.GF21410@us.ibm.com>
In-Reply-To: <20081013170610.GF21410@us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [RFC] Disk integrity in QEMU
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: Ryan Harper <ryanh@us.ibm.com>
Cc: Chris Wright <chrisw@redhat.com>, Mark McLoughlin <markmc@redhat.com>, kvm-devel <kvm-devel@lists.sourceforge.net>, Laurent Vivier <Laurent.Vivier@bull.net>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

Ryan Harper wrote:
> * Anthony Liguori <anthony@codemonkey.ws> [2008-10-09 12:00]:
>   
>> 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.
>>
>>     

With 16k writes I think we hit a pathological case with the particular 
storage backend we're using since it has many disks and the volume is 
striped.  Also the results a bit different when going through a file 
system verses a LVM partition (the later being the first data set).  
Presumably, this is because even with no flags, writes happen 
synchronously to a LVM partition.

Also, cache=off seems to do pretty terribly when operating on an ext3 
file.  I suspect this has to do with how ext3 implements O_DIRECT.

However, the data demonstrates pretty nicely that O_DSYNC gives you 
native write speed, but accelerated read speed which I think we agree is 
the desirable behavior.  cache=off never seems to outperform cache=wt 
which is another good argument for it being the default over cache=off.

Regards,

Anthony Liguori