From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=35623 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OBpFw-0006i8-Hv
	for qemu-devel@nongnu.org; Tue, 11 May 2010 09:12:19 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <paul@codesourcery.com>) id 1OBpFu-0001eY-VK
	for qemu-devel@nongnu.org; Tue, 11 May 2010 09:12:16 -0400
Received: from mail.codesourcery.com ([38.113.113.100]:52340)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <paul@codesourcery.com>) id 1OBpFu-0001eA-Ml
	for qemu-devel@nongnu.org; Tue, 11 May 2010 09:12:14 -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 14:12:02 +0100
References: <1273528310-7051-1-git-send-email-agraf@suse.de>
	<201005111315.08897.paul@codesourcery.com>
	<4BE950E0.5050107@codemonkey.ws>
In-Reply-To: <4BE950E0.5050107@codemonkey.ws>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201005111412.02809.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>, Alexander Graf <agraf@suse.de>, Christoph Hellwig <hch@lst.de>, qemu-devel@nongnu.org, armbru@redhat.com

> > cache=always (or a more scary name like cache=lie to defend against
> > idiots)
> > 
> >    Reads and writes are cached. Guest flushes are ignored.  Useful for
> >    dumb guests in non-critical environments.
> 
> I really don't believe that we should support a cache=lie.  There are
> many other obtain the same results.  For instance, mount your guest
> filesystem with barrier=0.

Ideally yes. However in practice I suspect this is still a useful option. Is 
it even possible to disable barriers in all cases (e.g. NTFS under windows)?

In a production environment it's probably not so useful - you're generally 
dealing with long lived, custom configured guests.

In a development environment the rules can be a bit different. For example if 
you're testing an OS installer then you really don't want to be passing magic 
mount options. If the host machine dies then you don't care about the state of 
the guest because you're going to start from scratch anyway.

Paul