From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=47426 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OBrma-0007Ur-4e
	for qemu-devel@nongnu.org; Tue, 11 May 2010 11:54:16 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <paul@codesourcery.com>) id 1OBrmY-00043q-If
	for qemu-devel@nongnu.org; Tue, 11 May 2010 11:54:07 -0400
Received: from mail.codesourcery.com ([38.113.113.100]:38387)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <paul@codesourcery.com>) id 1OBrmY-00043Z-A2
	for qemu-devel@nongnu.org; Tue, 11 May 2010 11:54:06 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive
Date: Tue, 11 May 2010 16:53:52 +0100
References: <1273528310-7051-1-git-send-email-agraf@suse.de>
	<201005111450.53273.paul@codesourcery.com>
	<4BE97A58.2070907@codemonkey.ws>
In-Reply-To: <4BE97A58.2070907@codemonkey.ws>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201005111653.53208.paul@codesourcery.com>
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: Kevin Wolf <kwolf@redhat.com>, armbru@redhat.com, qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>, Christoph Hellwig <hch@lst.de>

> > I disagree.  We should not be removing or rejecting features just because
> > they allow you to shoot yourself in the foot.  We probably shouldn't be
> > enabling them by default, but that's a whole different question.
> 
> I disagree and think the mentality severely hurts usability.  QEMU's
> role should be to enable features, not to simplify every obscure
> feature.  In general, if someone wants to accomplish something, we
> should try to provide a mechanism to accomplish it.
> cache=none|writeback|writethrough is an example of this.  No one other
> than QEMU can control how we open a file descriptor so we need to
> provide a knob for it.

Doesn't the same argument apply to the existing cache=writethrough?
i.e. if you want to avoid data loss you should make sure your guest issues 
flushes properly, and it's not something qemu should be trying to hack round 
be adding an implicit flushe after every write.

Paul