From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43836 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBsOC-0001Rd-6F for qemu-devel@nongnu.org; Tue, 11 May 2010 12:33:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBsO8-0001G6-Ps for qemu-devel@nongnu.org; Tue, 11 May 2010 12:33:00 -0400 Received: from mail2.shareable.org ([80.68.89.115]:32924) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBsO8-0001Er-LQ for qemu-devel@nongnu.org; Tue, 11 May 2010 12:32:56 -0400 Date: Tue, 11 May 2010 17:32:42 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive Message-ID: <20100511163242.GA27028@shareable.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE959B2.3090904@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Alexander Graf , armbru@redhat.com, qemu-devel@nongnu.org, Paul Brook , Christoph Hellwig 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. 2. barrier=0 does _not_ provide the cache=off behaviour. It only disables barriers; it does not prevent writing to the disk hardware. If you are doing a transient OS install, ideally you want an amount equal to your free RAM not written to disk until the end. barrier=0 does not achieve that. > 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? -- Jamie