[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 2/3] qcow2: Allow resize of images with internal snapshots
From: |
Max Reitz |
Subject: |
Re: [PATCH v2 2/3] qcow2: Allow resize of images with internal snapshots |
Date: |
Fri, 24 Apr 2020 12:40:42 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 |
On 24.04.20 00:17, Eric Blake wrote:
> We originally refused to allow resize of images with internal
> snapshots because the v2 image format did not require the tracking of
> snapshot size, making it impossible to safely revert to a snapshot
> with a different size than the current view of the image. But the
> snapshot size tracking was rectified in v3, and our recent fixes to
> qemu-img amend (see 0a85af35) guarantee that we always have a valid
> snapshot size. Thus, we no longer need to artificially limit image
> resizes, but it does become one more thing that would prevent a
> downgrade back to v2. And now that we support different-sized
> snapshots, it's also easy to fix reverting to a snapshot to apply the
> new size.
>
> Upgrade iotest 61 to cover this (we previously had NO coverage of
> refusal to resize while snapshots exist). Note that the amend process
> can fail but still have effects: in particular, since we break things
> into upgrade, resize, downgrade, a failure during resize does not roll
> back changes made during upgrade, nor does failure in downgrade roll
> back a resize. But this situation is pre-existing even without this
> patch; and without journaling, the best we could do is minimize the
> chance of partial failure by collecting all changes prior to doing any
> writes - which adds a lot of complexity but could still fail with EIO.
> On the other hand, we are careful that even if we have partial
> modification but then fail, the image is left viable (that is, we are
> careful to sequence things so that after each successful cluster
> write, there may be transient leaked clusters but no corrupt
> metadata). And complicating the code to make it more transaction-like
> is not worth the effort: a user can always request multiple 'qemu-img
> amend' changing one thing each, if they need finer-grained control
> over detecting the first failure than what they get by letting qemu
> decide how to sequence multiple changes.
>
> Signed-off-by: Eric Blake <address@hidden>
> ---
> block/qcow2-snapshot.c | 20 ++++++++++++++++----
> block/qcow2.c | 25 ++++++++++++++++++++++---
> tests/qemu-iotests/061 | 35 +++++++++++++++++++++++++++++++++++
> tests/qemu-iotests/061.out | 28 ++++++++++++++++++++++++++++
> 4 files changed, 101 insertions(+), 7 deletions(-)
Reviewed-by: Max Reitz <address@hidden>
signature.asc
Description: OpenPGP digital signature
- [PATCH v2 3/3] qcow2: Tweak comment about bitmaps vs. resize, (continued)
Re: [PATCH v2 1/3] block: Add blk_new_with_bs() helper, Stefan Hajnoczi, 2020/04/24
[PATCH v2 2/3] qcow2: Allow resize of images with internal snapshots, Eric Blake, 2020/04/23
- Re: [PATCH v2 2/3] qcow2: Allow resize of images with internal snapshots,
Max Reitz <=
Re: [PATCH v2 0/3] qcow2: Allow resize of images with internal snapshots, no-reply, 2020/04/23
Re: [PATCH v2 0/3] qcow2: Allow resize of images with internal snapshots, no-reply, 2020/04/23
Re: [PATCH v2 0/3] qcow2: Allow resize of images with internal snapshots, no-reply, 2020/04/23