From: Eric Blake <eblake@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: kwolf@redhat.com, den@openvz.org, jsnow@redhat.com, mreitz@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 1/2] qcow2: try load bitmaps only once
Date: Wed, 11 Apr 2018 08:22:36 -0500 [thread overview]
Message-ID: <b763ca01-d906-dbf8-2eb6-48e4140d2efe@redhat.com> (raw)
In-Reply-To: <20180411122606.367301-2-vsementsov@virtuozzo.com>
[-- Attachment #1: Type: text/plain, Size: 2923 bytes --]
On 04/11/2018 07:26 AM, Vladimir Sementsov-Ogievskiy wrote:
> Checking reopen by existence of some bitmaps is wrong, as it may be
> some other bitmaps, or on the other hand, user may remove bitmaps. This
> criteria is bad. To simplify things and make behavior more predictable
> let's just add a flag to remember, that we've already tried to load
> bitmaps on open and do not want do it again.
Wording suggestion:
Checking whether we are reopening an image based on the existence of
some bitmaps is wrong, as the set of bitmaps may have changed (for
example, the user may have added or removed bitmaps in the meantime).
To simplify things and make behavior more predictable, let's just add a
flag to remember whether we've already tried to load bitmaps, so that we
only attempt it on the initial open.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
> block/qcow2.h | 1 +
> block/qcow2.c | 16 ++++++++--------
> 2 files changed, 9 insertions(+), 8 deletions(-)
>
> @@ -1480,10 +1481,9 @@ static int coroutine_fn qcow2_do_open(BlockDriverState *bs, QDict *options,
> s->autoclear_features &= QCOW2_AUTOCLEAR_MASK;
> }
>
> - if (bdrv_dirty_bitmap_next(bs, NULL)) {
> - /* It's some kind of reopen with already existing dirty bitmaps. There
> - * are no known cases where we need loading bitmaps in such situation,
> - * so it's safer don't load them.
> + if (s->dirty_bitmaps_loaded) {
> + /* It's some kind of reopen. There are no known cases where we need
> + * loading bitmaps in such situation, so it's safer don't load them.
Pre-existing wording, but sounds better as:
There are no known cases where we need to reload bitmaps in such a
situation, so it's safer to skip them.
> *
> * Moreover, if we have some readonly bitmaps and we are reopening for
> * rw we should reopen bitmaps correspondingly.
> @@ -1491,13 +1491,13 @@ static int coroutine_fn qcow2_do_open(BlockDriverState *bs, QDict *options,
> if (bdrv_has_readonly_bitmaps(bs) &&
> !bdrv_is_read_only(bs) && !(bdrv_get_flags(bs) & BDRV_O_INACTIVE))
> {
> - bool header_updated = false;
> qcow2_reopen_bitmaps_rw_hint(bs, &header_updated, &local_err);
> - update_header = update_header && !header_updated;
> }
> - } else if (qcow2_load_dirty_bitmaps(bs, &local_err)) {
> - update_header = false;
> + } else {
> + header_updated = qcow2_load_dirty_bitmaps(bs, &local_err);
> + s->dirty_bitmaps_loaded = true;
> }
> + update_header = update_header && !header_updated;
Could write this as 'update_header &= !header_updated;'
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]
next prev parent reply other threads:[~2018-04-11 13:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-11 12:26 [Qemu-devel] [PATCH v2 0/2] bitmaps persistent and migration fixes Vladimir Sementsov-Ogievskiy
2018-04-11 12:26 ` [Qemu-devel] [PATCH v2 1/2] qcow2: try load bitmaps only once Vladimir Sementsov-Ogievskiy
2018-04-11 13:22 ` Eric Blake [this message]
2018-04-11 13:45 ` Vladimir Sementsov-Ogievskiy
2018-04-11 16:33 ` Max Reitz
2018-04-11 12:26 ` [Qemu-devel] [PATCH v2 2/2] iotests: fix 169 Vladimir Sementsov-Ogievskiy
2018-04-11 16:41 ` Max Reitz
2018-04-11 16:50 ` [Qemu-devel] [PATCH v2 0/2] bitmaps persistent and migration fixes 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=b763ca01-d906-dbf8-2eb6-48e4140d2efe@redhat.com \
--to=eblake@redhat.com \
--cc=den@openvz.org \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.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).