From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54755 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBy2j-0001wg-3L for qemu-devel@nongnu.org; Tue, 11 May 2010 18:35:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBy1a-000719-VC for qemu-devel@nongnu.org; Tue, 11 May 2010 18:34:04 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:46001) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBy1a-00070q-Mt for qemu-devel@nongnu.org; Tue, 11 May 2010 18:34:02 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive Date: Tue, 11 May 2010 23:33:48 +0100 References: <1273528310-7051-1-git-send-email-agraf@suse.de> <201005111653.53208.paul@codesourcery.com> <4BE98F3A.3020503@codemonkey.ws> In-Reply-To: <4BE98F3A.3020503@codemonkey.ws> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005112333.48873.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Kevin Wolf , Christoph Hellwig , armbru@redhat.com, Alexander Graf > On 05/11/2010 10:53 AM, Paul Brook wrote: > >>> I disagree. We should not be removing or rejecting features just > >>> because they allow you to shoot yourself in the foot. We probably > >>> shouldn't be enabling them by default, but that's a whole different > >>> question. > >> > >> I disagree and think the mentality severely hurts usability. QEMU's > >> role should be to enable features, not to simplify every obscure > >> feature. In general, if someone wants to accomplish something, we > >> should try to provide a mechanism to accomplish it. > >> cache=none|writeback|writethrough is an example of this. No one other > >> than QEMU can control how we open a file descriptor so we need to > >> provide a knob for it. > > > > Doesn't the same argument apply to the existing cache=writethrough? > > i.e. if you want to avoid data loss you should make sure your guest > > issues flushes properly, and it's not something qemu should be trying to > > hack round be adding an implicit flushe after every write. > > cache is the host page cache acting as an extended disk cache. In > writethrough mode, the behavior is identical to writethrough on a normal > disk cache in that all operations are completed only when sent down to > the next storage layer. IMO this is a bug. Making host pagecache writethrough but still having a volatile writeback disk cache seems like a complete waste of time. I can see the advantage of disabling host pagecache (avoid double caching in host RAM), but having different levels of cache be writethrough/writeback seems extremely suspect. It's also occurred to me that you're also basing your arguments on the assumption that host pagecache is volatile. On a machine with a good UPS this is not true. In the even of external power failure the UPS will flush the host page cache and cleanly shut the machine down. As with battery-backed RAID cards, it's entirely reasonable to consider the cache to be non-volatile storage and ignore the flush requests. If you don't trust your host OS in this situation then you're into a whole different level of pain, and raises obvious questions about the firmware running on your storage subsystem. Paul