From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46067 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBusF-0008Js-2g for qemu-devel@nongnu.org; Tue, 11 May 2010 15:12:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBusC-0006QY-Sy for qemu-devel@nongnu.org; Tue, 11 May 2010 15:12:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56301) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBusC-0006QP-Ks for qemu-devel@nongnu.org; Tue, 11 May 2010 15:12:08 -0400 Message-ID: <4BE9ABF2.7090902@redhat.com> Date: Tue, 11 May 2010 22:11:46 +0300 From: Avi Kivity 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> <201005111412.02809.paul@codesourcery.com> <4BE959B2.3090904@codemonkey.ws> <201005111450.53273.paul@codesourcery.com> <4BE97A58.2070907@codemonkey.ws> In-Reply-To: <4BE97A58.2070907@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , armbru@redhat.com, Alexander Graf , qemu-devel@nongnu.org, Paul Brook , Christoph Hellwig On 05/11/2010 06:40 PM, Anthony Liguori wrote: > > But if the goal is to make sure that fsync's don't result in data > actually being on disk, there are many other ways to accomplish this. > First, for the vast majority of users, this is already the case > because ext3 defaults to disabling barriers. Alex is running into > this issue only because SuSE enables barriers by default for ext3 and > fsync()'s are horribly slow on ext3. The fact that this is measurable > is purely a statement of ext3 suckage and a conscious decision by the > SuSE team to live with that suckage. It shouldn't be nearly as bad on > ext4. > There is a huge difference between disabling barriers and cache=volatile. With barrier=0, data is still forced out of host pagecache and into disk cache; it's simply not forced from disk cache to the platter. But since the disk cache is very limited, you'll still be running at disk speed. With cache=volatile and enough memory you'll never wait for the disk to write data. > > On the other hand, the cost of adding another caching option is pretty > significant. Very few users really understand what caching options > they should use under what circumstance. Adding another option will > just make that worse. The fact that this new option can result in > data corruption that won't occur under normal circumstances is troubling. I don't think it's a real problem with proper naming, but we can always hide the option behind a ./configure --enable-developer-options. > >> Mounting a filesystem with barrier=0 is not a good answer because it's a >> global setting. While my qemu VM may be disposable, it's unlikely >> that the >> same is true of the rest of my machine. > > You can have multiple mounts. In fact, you can just make a loopback > mount within your existing file system which means that you don't even > have to muck with your disk. > > If your VM is disposable, then shouldn't you be using -snapshot? For my use case (autotest) the VM is not disposable (it's reused between tests) but I don't care about the data in case of a host crash. > > >> By your argument linux shouldn't be >> allowing me to do that in the first place because a dumb sysadmin >> could use >> that option on the filesystem containing the mail store. In fact with >> the >> average user that's *likely* to happen because they'll only have a >> single >> partition on their machine. > > We aren't preventing sophisticated users from doing sophisticated > things. But why should we simplify something that most people don't > need and if they accidentally use it, bad things will happen? We don't have a real alternative. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.