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

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

[Kevin Wolf]

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. It's a bit ugly with -drive because it would add a new option
that is invalid/ignored for everything except qcow2.

Or maybe instead of a new option, add a cache mode almost-writethrough?
 (I'm having a hard time finding a good name...) But then, we're already
trying to get rid of the cache option and replace it by three separate
switches, so adding a fourth dimension might not be the smartest move ever.

(The correct solution is, of course, -blockdev which would allow
per-driver runtime options, but well...)

Kevin

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

[Paolo Bonzini]

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...

Paolo

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

[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.

Stefan

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

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

[Stefan Hajnoczi]

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