From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=32782 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCDUr-0005Gh-11 for qemu-devel@nongnu.org; Wed, 12 May 2010 11:05:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCDUl-0006NQ-Su for qemu-devel@nongnu.org; Wed, 12 May 2010 11:05:15 -0400 Received: from cantor.suse.de ([195.135.220.2]:44343 helo=mx1.suse.de) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCDUl-0006Mi-MS for qemu-devel@nongnu.org; Wed, 12 May 2010 11:05:11 -0400 Message-ID: <4BEAC3A4.6030503@suse.de> Date: Wed, 12 May 2010 17:05:08 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1273528310-7051-1-git-send-email-agraf@suse.de> <1273528310-7051-2-git-send-email-agraf@suse.de> <1273528310-7051-3-git-send-email-agraf@suse.de> <4BE91708.7050307@redhat.com> In-Reply-To: <4BE91708.7050307@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, hch@lst.de Kevin Wolf wrote: > Am 10.05.2010 23:51, schrieb Alexander Graf: > >> Usually the guest can tell the host to flush data to disk. In some cases we >> don't want to flush though, but try to keep everything in cache. >> >> So let's add a new parameter to -drive that allows us to set the flushing >> behavior to "on" or "off", defaulting to enabling the guest to flush. >> >> Signed-off-by: Alexander Graf >> > > What about another cache=... value instead of adding more options? I'm > quite sure you'll only ever need this with writeback caching. So we > could have cache=none|writethrough|writeback|wb-noflush or something > like that. > > Yes, cache=volatile seems reasonable. Or cache=unsafe. >> --- >> block/raw-posix.c | 13 +++++++++++++ >> > > This is obviously wrong. If you want to introduce new behaviour to the > block layer, you must do it consistently and not just for one block > driver. So these changes should be made to the generic functions in > block.c instead. > How so? The callback functions are called using bdrv->drv->xxx. If I modify that pointer, I end up affecting all other virtual disks as well. Alex