From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUGRh-0005hT-Rc for Qemu-devel@nongnu.org; Tue, 15 May 2012 08:01:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUGRZ-0008U0-AV for Qemu-devel@nongnu.org; Tue, 15 May 2012 08:01:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59585) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUGRZ-0008To-31 for Qemu-devel@nongnu.org; Tue, 15 May 2012 08:01:33 -0400 Message-ID: <4FB24593.5050106@redhat.com> Date: Tue, 15 May 2012 14:01:23 +0200 From: Kevin Wolf MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Interface for enabling lazy refcount updates in qcow2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Qemu-devel@nongnu.org Cc: Paolo Bonzini , Stefan Hajnoczi , Markus Armbruster Hi all, after having implemented refcount fixing in qcow2's img_check, I'm now wondering what the best way is to allow users to optionally enable the "QED mode" for cache=writethrough images where refcount updates aren't written out immediately. Basically the two options are: 1. Store it in the image with a compatible feature flag and require that the flag is set during image creation (and never updated) 2. Have an option on the command line and pass it each time you start a VM and want to enable it I'm leaning towards option 2 because it is more flexible and consistent with the other caching options that aren't stored in the image file either. It's a bit ugly with -drive because it would add a new option that is invalid/ignored for everything except qcow2. Or maybe instead of a new option, add a cache mode almost-writethrough? (I'm having a hard time finding a good name...) But then, we're already trying to get rid of the cache option and replace it by three separate switches, so adding a fourth dimension might not be the smartest move ever. (The correct solution is, of course, -blockdev which would allow per-driver runtime options, but well...) Kevin