[Top][All Lists]
[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