diff options
| author | Max Reitz | 2020-07-30 14:02:33 +0200 |
|---|---|---|
| committer | Eric Blake | 2020-08-03 15:59:37 +0200 |
| commit | fe16c7ddf82b25e54cb76936a4cdf6bf9327ece5 (patch) | |
| tree | c7b5141c7969224e80992cf99155985cf727fef4 /tests | |
| parent | Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2020-08-03' into ... (diff) | |
| download | qemu-fe16c7ddf82b25e54cb76936a4cdf6bf9327ece5.tar.gz qemu-fe16c7ddf82b25e54cb76936a4cdf6bf9327ece5.tar.xz qemu-fe16c7ddf82b25e54cb76936a4cdf6bf9327ece5.zip | |
qcow2: Release read-only bitmaps when inactivated
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).
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200730120234.49288-2-mreitz@redhat.com>
Tested-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Diffstat (limited to 'tests')
0 files changed, 0 insertions, 0 deletions