From: Paolo Bonzini <pbonzini@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>,
Qemu-devel@nongnu.org,
Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] Interface for enabling lazy refcount updates in qcow2
Date: Tue, 15 May 2012 14:42:54 +0200 [thread overview]
Message-ID: <4FB24F4E.6000705@redhat.com> (raw)
In-Reply-To: <4FB24593.5050106@redhat.com>
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
next prev parent reply other threads:[~2012-05-15 12:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-15 12:01 [Qemu-devel] Interface for enabling lazy refcount updates in qcow2 Kevin Wolf
2012-05-15 12:42 ` Paolo Bonzini [this message]
2012-05-21 14:34 ` Stefan Hajnoczi
2012-05-21 15:23 ` Kevin Wolf
2012-05-23 10:45 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FB24F4E.6000705@redhat.com \
--to=pbonzini@redhat.com \
--cc=Qemu-devel@nongnu.org \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=stefanha@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.