From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MiFkk-0007G0-HZ
	for qemu-devel@nongnu.org; Mon, 31 Aug 2009 18:53:34 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MiFkg-0007Em-2g
	for qemu-devel@nongnu.org; Mon, 31 Aug 2009 18:53:34 -0400
Received: from [199.232.76.173] (port=43148 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MiFkf-0007Ej-R3
	for qemu-devel@nongnu.org; Mon, 31 Aug 2009 18:53:29 -0400
Received: from mail-pz0-f186.google.com ([209.85.222.186]:49521)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1MiFkf-0001l5-Eu
	for qemu-devel@nongnu.org; Mon, 31 Aug 2009 18:53:29 -0400
Received: by pzk16 with SMTP id 16so192431pzk.18
	for <qemu-devel@nongnu.org>; Mon, 31 Aug 2009 15:53:28 -0700 (PDT)
Message-ID: <4A9C5463.4090904@codemonkey.ws>
Date: Mon, 31 Aug 2009 17:53:23 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 1/4] block: add enable_write_cache flag
References: <20090831201627.GA4811@lst.de>
	<20090831201651.GA4874@lst.de>	<20090831220950.GB24318@shareable.org>
	<20090831221622.GA8834@lst.de>
In-Reply-To: <20090831221622.GA8834@lst.de>
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.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: Christoph Hellwig <hch@lst.de>
Cc: qemu-devel@nongnu.org

Christoph Hellwig wrote:
>> If an unsafe mode is desired (I think it is, for those throwaway
>> testing VMs, or during OS installs), I suggest adding cache=volatile:
>>
>>     cache=none
>>         O_DIRECT, fdatasync, advertise volatile write cache
>>
>>     cache=writethrough
>>         O_SYNC, do not advertise
>>
>>     cache=writeback
>>         fdatasync, advertise volatile write cache
>>
>>     cache=volatile
>>         nothing (perhaps fdatasync on QEMU blockdev close)
>>     
>
> Fine withe me, let the flame war begin :)
>   

I think we should pity our poor users and avoid adding yet another 
obscure option that is likely to be misunderstood.

Can someone do some benchmarking with cache=writeback and fdatasync 
first and quantify what the real performance impact is?

I think the two reasonable options are 1) make cache=writeback safe, 
avoid a massive perf decrease in the process 2) keep cache=writeback as 
a no-guarantees option.

Regards,

Anthony Liguori