From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=39799 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OHIIU-000329-FA
	for qemu-devel@nongnu.org; Wed, 26 May 2010 11:13:31 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OHIIS-0001In-Qj
	for qemu-devel@nongnu.org; Wed, 26 May 2010 11:13:29 -0400
Received: from mx1.redhat.com ([209.132.183.28]:2365)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OHIIS-0001HX-Kb
	for qemu-devel@nongnu.org; Wed, 26 May 2010 11:13:28 -0400
Message-ID: <4BFD3A8D.20006@redhat.com>
Date: Wed, 26 May 2010 18:13:17 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH] Add cache=volatile parameter to -drive
References: <1274091292-4812-1-git-send-email-agraf@suse.de>
	<4BF13D5E.8090006@codemonkey.ws> <4BFD1CC7.4080807@redhat.com>
	<4BFD2730.8000006@codemonkey.ws>
In-Reply-To: <4BFD2730.8000006@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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.nongnu.org/archive/html/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: Anthony Liguori <anthony@codemonkey.ws>
Cc: kwolf@redhat.com, hch@lst.de, Alexander Graf <agraf@suse.de>, qemu-devel@nongnu.org

On 05/26/2010 04:50 PM, Anthony Liguori wrote:
>> In fact, btrfs is currently unusable for virt because O_SYNC writes 
>> inflate a guest write to a host write. by a huge factor (50x-100x).  
>> cache=writethrough is 100% unusable, cache=writeback is barely 
>> tolerable.  As of 2.6.32, cache=volatile is probably required to get 
>> something resembling reasonable performance on btrfs.
>>
>> Of course, we expect that btrfs will improve in time, but still it 
>> doesn't seem to be fsync friendly.
>
>
> So you're suggesting that anyone who uses virt on btrfs should be 
> prepared to deal with data corruption on host failure? 

No.

> That sounds to me like btrfs isn't ready for real workloads.

The btrfs developers aren't saying anything different.  But people still 
want to try it out (to wire up snapshotting to management, for example).

-- 
error compiling committee.c: too many arguments to function