qemu-devel
[Top][All Lists]
Advanced

[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>

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]