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