From: Max Reitz <mreitz@redhat.com>
To: qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/3] qcow2: Implement bdrv_amend_options
Date: Wed, 28 Aug 2013 14:05:45 +0200 [thread overview]
Message-ID: <521DE799.1080607@redhat.com> (raw)
In-Reply-To: <20130828114826.GG2743@dhcp-200-207.str.redhat.com>
Hi,
Am 28.08.2013 13:48, schrieb Kevin Wolf:
> Am 28.08.2013 um 13:39 hat Max Reitz geschrieben:
>>>> + /* clear incompatible features */
>>>> + if (s->incompatible_features & QCOW2_INCOMPAT_DIRTY) {
>>>> + BdrvCheckResult result;
>>>> + ret = qcow2_check(bs, &result, BDRV_FIX_ERRORS);
>>>> + if (ret < 0) {
>>>> + return ret;
>>>> + }
>>> This is unnecessary: The image could be opened, so we know that it was
>>> clean when we started. We also know that we haven't crashed yet, so if we
>>> flush all in-memory data, we'll have a consistent on-disk state again.
>>>
>>> qcow2_mark_clean() already calls bdrv_flush(bs), so it does everything
>>> that is needed in this respect.
>> So that flag should always be already cleared at this point anyway?
> The qcow2_mark_clean() call is on the next line (which you removed from
> the quote), so not at this point but one line later. But yeah, it's done
> by other code.
Yes, I was referring to other code (which cleans the image right at
opening).
>>>> + } else if (!strcmp(options[i].name, "encryption")) {
>>>> + if (options[i].value.n != !!s->crypt_method) {
>>>> + fprintf(stderr, "Changing the encryption flag is not "
>>>> + "supported.\n");
>>>> + return -ENOTSUP;
>>>> + }
>>>> + } else if (!strcmp(options[i].name, "cluster_size")) {
>>>> + if (options[i].value.n && (options[i].value.n != s->cluster_size)) {
>>>> + fprintf(stderr, "Changing the cluster size is not "
>>>> + "supported.\n");
>>>> + return -ENOTSUP;
>>>> + }
>>>> + } else if (!strcmp(options[i].name, "lazy_refcounts")) {
>>>> + /* TODO: detect whether this flag was indeed explicitly given */
>>>> + lazy_refcounts = options[i].value.n;
>>> I can see two ways to achieve this:
>>>
>>> 1. Add a new field 'bool assigned' to QEMUOptionParameter, which would
>>> be cleared before parsing an option string and set for each option in
>>> set_option_parameter()
>>>
>>> 2. Get the QemuOpts conversion series in and add a function that tells
>>> whether a given option was specified or not.
>>>
>>> The same TODO should actually apply to encryption and cluster_size as
>>> well, shouldn't it?
>> Kind of; however, a cluster_size of 0 seems invalid to me, therefore
>> it is pretty easy to detect that option not being given.
> Depends on whether you think that 'qemu-img amend -o cluster_size=0' is
> a valid way of saying that you don't want to change the cluster size. I
> would prefer to error out.
No, I just missed the default for that option not being zero. Sorry, my
fault.
Max
next prev parent reply other threads:[~2013-08-28 12:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-28 8:08 [Qemu-devel] [PATCH 0/3] block/qcow2: Image file option amendment Max Reitz
2013-08-28 8:08 ` [Qemu-devel] [PATCH 1/3] block: " Max Reitz
2013-08-28 10:03 ` Kevin Wolf
2013-08-28 12:22 ` Eric Blake
2013-08-28 12:26 ` Kevin Wolf
2013-08-28 8:08 ` [Qemu-devel] [PATCH 2/3] qcow2: Implement bdrv_amend_options Max Reitz
2013-08-28 11:06 ` Kevin Wolf
2013-08-28 11:39 ` Max Reitz
2013-08-28 11:48 ` Kevin Wolf
2013-08-28 12:05 ` Max Reitz [this message]
2013-08-28 12:12 ` Kevin Wolf
2013-08-28 8:08 ` [Qemu-devel] [PATCH 3/3] qemu-iotest: qcow2 image option amendment Max Reitz
2013-08-28 11:40 ` Kevin Wolf
2013-08-28 11:47 ` Max Reitz
2013-08-28 11:54 ` Kevin Wolf
2013-08-28 12:06 ` Max Reitz
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=521DE799.1080607@redhat.com \
--to=mreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).