From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MiF4d-0002zm-Um for qemu-devel@nongnu.org; Mon, 31 Aug 2009 18:10:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MiF4Z-0002o6-ST for qemu-devel@nongnu.org; Mon, 31 Aug 2009 18:10:03 -0400 Received: from [199.232.76.173] (port=51870 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MiF4Z-0002nh-Li for qemu-devel@nongnu.org; Mon, 31 Aug 2009 18:09:59 -0400 Received: from mx20.gnu.org ([199.232.41.8]:41073) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MiF4Z-00032q-Ae for qemu-devel@nongnu.org; Mon, 31 Aug 2009 18:09:59 -0400 Received: from mail2.shareable.org ([80.68.89.115]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MiF4X-0007hH-WC for qemu-devel@nongnu.org; Mon, 31 Aug 2009 18:09:58 -0400 Date: Mon, 31 Aug 2009 23:09:50 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 1/4] block: add enable_write_cache flag Message-ID: <20090831220950.GB24318@shareable.org> References: <20090831201627.GA4811@lst.de> <20090831201651.GA4874@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090831201651.GA4874@lst.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: qemu-devel@nongnu.org Christoph Hellwig wrote: > We would have to claim one for data=writeback to be safe, but for I will > follow Avi's opinion that it is a useless mode and should be our > dedicated unsafe mode. If anyone disagrees please start the flame > thrower now and I will change it. Otherwise a documentation patch will > follow to explicitly document data=writeback as unsafe. *Opening flame thrower!* Unsafe, useless? It's the most useful mode when you're starting and stopping VMs regularly, or if you can't use O_DIRECT. It's safe if fdatasync is called - in other words not advertising a write cache is silly. I haven't measured but I'd expect it to be much faster than O_SYNC on some host hardware, for the same reason that barriers + volatile write cache are much faster on some host hardware than disabling the write cache. Right now, on a Linux host O_SYNC is unsafe with hardware that has a volatile write cache. That might not be changed, but if it is than performance with cache=writethrough will plummet (due to issuing a CACHE FLUSH to the hardware after every write), while performance with cache=writeback will be reasonable. If an unsafe mode is desired (I think it is, for those throwaway testing VMs, or during OS installs), I suggest adding cache=volatile: cache=none O_DIRECT, fdatasync, advertise volatile write cache cache=writethrough O_SYNC, do not advertise cache=writeback fdatasync, advertise volatile write cache cache=volatile nothing (perhaps fdatasync on QEMU blockdev close) When using guests OSes which issue CACHE FLUSH commands (that's a guest config issue), why would you ever use cache=writethrough? cache=writeback should be faster and equally safe - provided you do actually advertise the write cache! So please do! Not doing so is silly. -- Jamie