From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:32913) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUH5v-00056m-BB for Qemu-devel@nongnu.org; Tue, 15 May 2012 08:43:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUH5l-0000sj-6G for Qemu-devel@nongnu.org; Tue, 15 May 2012 08:43:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59272) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUH5i-0000sG-E6 for Qemu-devel@nongnu.org; Tue, 15 May 2012 08:43:05 -0400 Message-ID: <4FB24F4E.6000705@redhat.com> Date: Tue, 15 May 2012 14:42:54 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <4FB24593.5050106@redhat.com> In-Reply-To: <4FB24593.5050106@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Interface for enabling lazy refcount updates in qcow2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Markus Armbruster , Qemu-devel@nongnu.org, Stefan Hajnoczi Il 15/05/2012 14:01, Kevin Wolf ha scritto: > 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. I see one problem with option 2. You cannot really change the QEMU default from writethrough to writethough-lazy, because old versions of QEMU will not be able to read an image in need of repairs, and will not have a powerful-enough qemu-img to repair it. And if it is off by default at the QEMU level, nobody will use it. So in some sense it is option 1 that gives you more flexibility. Of course, leave the feature off by default at the qemu-img level, and nobody will use it. However, you could make it off by default for compatibility level <= 1.1 and on by default for compatibility level >= 1.2. Thus, with option 1 there is some chance that people actually use it. > (The correct solution is, of course, -blockdev which would allow > per-driver runtime options, but well...) If you go with option 1, later you could add an option to -blockdev to override the image default. If you go with option 2, you're stuck with ugliness forever. I'm not worried very much of the ugliness in -drive, but more about how it would propagate to libvirt and friends... Paolo