Re: [Qemu-devel] Interface for enabling lazy refcount updates in qcow2

[Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>]

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.

Stefan