From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45531 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBxgV-0005I7-T3 for qemu-devel@nongnu.org; Tue, 11 May 2010 18:12:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBxfi-0004DO-Rb for qemu-devel@nongnu.org; Tue, 11 May 2010 18:11:31 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:38038) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBxfi-0004DG-Hz for qemu-devel@nongnu.org; Tue, 11 May 2010 18:11:26 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive Date: Tue, 11 May 2010 23:11:12 +0100 References: <1273528310-7051-1-git-send-email-agraf@suse.de> <20100511182020.GB30446@shareable.org> <201005112258.52054.paul@codesourcery.com> In-Reply-To: <201005112258.52054.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005112311.12875.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 , armbru@redhat.com, Alexander Graf , Christoph Hellwig > > Paul Brook wrote: > > > cache=none: > > > No host caching. Reads and writes both go directly to underlying > > > storage. > > > > > > Useful to avoid double-caching. > > > > > > cache=writethrough > > > > > > Reads are cached. Writes go directly to underlying storage. Useful > > > for > > > > > > broken guests that aren't aware of drive caches. > > > > These are misleading descriptions - because cache=none does not push > > writes down to powerfail-safe storage, while cache=writethrough might. > > If so, then this is a serious bug. .. though it may be a kernel bug rather that a qemu bug, depending on the exact details. Either way, I consider any mode that inhibits host filesystem write cache but not volatile drive cache to be pretty worthless. Either we guaranteed data integrity on completion or we don't. Paul