On 06/28/2018 10:39 AM, Kevin Wolf wrote:
If we managed to allocate the clusters, but then failed to write the
data, there's a good chance that we'll still be able to free the
clusters again in order to avoid cluster leaks (the refcounts are
cached, so even if we can't write them out right now, we may be able to
do so when the VM is resumed after a werror=stop/enospc pause).
Signed-off-by: Kevin Wolf <kw...@redhat.com>
---
block/qcow2.h | 1 +
block/qcow2-cluster.c | 11 +++++++++++
block/qcow2.c | 2 ++
3 files changed, 14 insertions(+)
Hmm, I wonder if this interacts poorly with my proposed test addition
for HUGE images, which is still pending review:
https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg05488.html
https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg04542.html
(time for me to go testing...)
+++ b/block/qcow2.c
@@ -1777,6 +1777,8 @@ static coroutine_fn int
qcow2_handle_l2meta(BlockDriverState *bs,
if (ret) {
goto out;
}
+ } else {
+ qcow2_alloc_cluster_abort(bs, l2meta);
}
None of our existing tests caught this? But it looks right to me.
Reviewed-by: Eric Blake <ebl...@redhat.com>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
