On Mon, May 21, 2012 at 4:23 PM, Kevin Wolf <kw...@redhat.com> wrote: > 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.
Paolo's suggestion (option 1) seems cleanest even though it doesn't give a command-line option yet (it leaves that open for the future). Stefan
