From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWUSw-0007M4-Uc for Qemu-devel@nongnu.org; Mon, 21 May 2012 11:24:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWUSn-0002pg-Qa for Qemu-devel@nongnu.org; Mon, 21 May 2012 11:24:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60345) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWUSn-0002pG-J9 for Qemu-devel@nongnu.org; Mon, 21 May 2012 11:24:01 -0400 Message-ID: <4FBA5DFF.9080606@redhat.com> Date: Mon, 21 May 2012 17:23:43 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <4FB24593.5050106@redhat.com> <4FB24F4E.6000705@redhat.com> <20120521143432.GA13300@stefanha-thinkpad.localdomain> In-Reply-To: <20120521143432.GA13300@stefanha-thinkpad.localdomain> Content-Type: text/plain; charset=ISO-8859-1 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: Stefan Hajnoczi Cc: Paolo Bonzini , Qemu-devel@nongnu.org, Markus Armbruster Am 21.05.2012 16:34, schrieb Stefan Hajnoczi: > On Tue, May 15, 2012 at 02:42:54PM +0200, Paolo Bonzini wrote: >> 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... > > I'm not sure how you plan to implement the writethrough optimizations > but won't we need a image file header flag anyway to mark this image as > "refcounts off"? If we don't have the flag then we'd have to scan the > metadata of every image on open? > > So I think option 1 makes sense in one form or another anyway. Yes, you need an (incompatible) feature flag for "refcounts are unreliable" in any case. It is set whenever a refcount update is skipped and cleared after a clean close, a bdrv_check on open or possibly a time-based flush. My question is about another (compatible) flag "qemu may set the refcount unreliable bit", which could as well be a runtime option. Kevin