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

[Kevin Wolf]

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