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

[Stefan Hajnoczi]

On Mon, May 21, 2012 at 4:23 PM, Kevin Wolf <address@hidden> 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