From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41496 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBt3x-0004JQ-4M for qemu-devel@nongnu.org; Tue, 11 May 2010 13:16:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBt3u-0001C9-K2 for qemu-devel@nongnu.org; Tue, 11 May 2010 13:16:08 -0400 Received: from mail-qy0-f188.google.com ([209.85.221.188]:62142) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBt3u-0001Br-AT for qemu-devel@nongnu.org; Tue, 11 May 2010 13:16:06 -0400 Received: by qyk26 with SMTP id 26so8028294qyk.19 for ; Tue, 11 May 2010 10:16:04 -0700 (PDT) Message-ID: <4BE990CE.40505@codemonkey.ws> Date: Tue, 11 May 2010 12:15:58 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive References: <1273528310-7051-1-git-send-email-agraf@suse.de> <201005111315.08897.paul@codesourcery.com> <4BE950E0.5050107@codemonkey.ws> <201005111412.02809.paul@codesourcery.com> <4BE959B2.3090904@codemonkey.ws> <20100511163242.GA27028@shareable.org> In-Reply-To: <20100511163242.GA27028@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Kevin Wolf , Alexander Graf , armbru@redhat.com, qemu-devel@nongnu.org, Paul Brook , Christoph Hellwig On 05/11/2010 11:32 AM, Jamie Lokier wrote: > Anthony Liguori wrote: > >> On 05/11/2010 08:12 AM, Paul Brook wrote: >> >>>>> 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. >>> >>> >> Then create a mount point on your host and mount the host file system >> under that mount with barrier=0. >> > Two reasons that advice doesn't work: > > 1. It doesn't work in many environments. You can't mount a filesystem > with barrier=0 in one place and barrier=1 on a different point, and > there's ofen only one host partition. > qemu-img create -f raw foo.img 10G mkfs.ext3 foo.img mount -oloop,rw,barrier=1 -t ext3 foo.img mnt Works perfectly fine. > 2. barrier=0 does _not_ provide the cache=off behaviour. It only > disables barriers; it does not prevent writing to the disk hardware. > The proposal has nothing to do with cache=off. >> The problem with options added for developers is that those options are >> very often accidentally used for production. >> > We already have risky cache= options. Also, do we call fdatasync > (with barrier) on _every_ write for guests which disable the > emulated disk cache? > None of our cache= options should result in data corruption on power loss. If they do, it's a bug. Regards, Anthony Liguori > -- Jamie >