qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] Interface for enabling lazy refcount updates in qcow2
Date: Tue, 15 May 2012 14:42:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]