From: Peter Krempa <pkrempa@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-block@nongnu.org, John Snow <jsnow@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH 1/2] qcow2: Release read-only bitmaps when inactivated
Date: Thu, 30 Jul 2020 16:22:00 +0200 [thread overview]
Message-ID: <20200730142200.GC2101@angien.pipo.sk> (raw)
In-Reply-To: <20200730120234.49288-2-mreitz@redhat.com>
On Thu, Jul 30, 2020 at 14:02:33 +0200, Max Reitz wrote:
> During migration, we release all bitmaps after storing them on disk, as
> long as they are (1) stored on disk, (2) not read-only, and (3)
> consistent.
>
> (2) seems arbitrary, though. The reason we do not release them is
> because we do not write them, as there is no need to; and then we just
> forget about all bitmaps that we have not written to the file. However,
> read-only persistent bitmaps are still in the file and in sync with
> their in-memory representation, so we may as well release them just like
> any R/W bitmap that we have updated.
>
> It leads to actual problems, too: After migration, letting the source
> continue may result in an error if there were any bitmaps on read-only
> nodes (such as backing images), because those have not been released by
> bdrv_inactive_all(), but bdrv_invalidate_cache_all() attempts to reload
> them (which fails, because they are still present in memory).
>
I've tested it with same commands as I've used before and now the 'cont'
succeeds and also the bitmaps after the cont call are loaded and active
at least according to 'query-named-block-nodes'
Tested-by: Peter Krempa <pkrempa@redhat.com>
next prev parent reply other threads:[~2020-07-30 14:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-30 12:02 [PATCH 0/2] qcow2: Release read-only bitmaps when inactivated Max Reitz
2020-07-30 12:02 ` [PATCH 1/2] " Max Reitz
2020-07-30 14:22 ` Peter Krempa [this message]
2020-07-30 14:54 ` Eric Blake
2020-08-05 11:06 ` Vladimir Sementsov-Ogievskiy
2020-07-30 12:02 ` [PATCH 2/2] iotests/169: Test source cont with backing bmap Max Reitz
2020-07-30 14:38 ` Eric Blake
2020-07-30 14:19 ` [PATCH 0/2] qcow2: Release read-only bitmaps when inactivated Eric Blake
2020-08-05 8:15 ` Vladimir Sementsov-Ogievskiy
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=20200730142200.GC2101@angien.pipo.sk \
--to=pkrempa@redhat.com \
--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).