All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Eric Blake <eblake@redhat.com>, qemu-devel@nongnu.org
Cc: kwolf@redhat.com, qemu-block@nongnu.org
Subject: Re: [PATCH v2 2/3] qcow2: Allow resize of images with internal snapshots
Date: Fri, 24 Apr 2020 12:40:42 +0200	[thread overview]
Message-ID: <d81b626f-25a0-7f88-9788-a44b6a6222ee@redhat.com> (raw)
In-Reply-To: <20200423221707.477404-3-eblake@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 2427 bytes --]

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 <eblake@redhat.com>
> ---
>  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 <mreitz@redhat.com>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-04-24 10:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-23 22:17 [PATCH v2 0/3] qcow2: Allow resize of images with internal snapshots Eric Blake
2020-04-23 22:17 ` [PATCH v2 1/3] block: Add blk_new_with_bs() helper Eric Blake
2020-04-24  9:53   ` Max Reitz
2020-04-24  9:56     ` Max Reitz
2020-04-24 10:02       ` Max Reitz
2020-04-24 14:18         ` Eric Blake
2020-04-24 14:25           ` Max Reitz
2020-04-24 12:23   ` Stefan Hajnoczi
2020-04-23 22:17 ` [PATCH v2 2/3] qcow2: Allow resize of images with internal snapshots Eric Blake
2020-04-24 10:40   ` Max Reitz [this message]
2020-04-23 22:17 ` [PATCH v2 3/3] qcow2: Tweak comment about bitmaps vs. resize Eric Blake
2020-04-24 10:41   ` Max Reitz
2020-04-23 22:28 ` [PATCH v2 0/3] qcow2: Allow resize of images with internal snapshots no-reply
2020-04-23 22:32 ` no-reply
2020-04-23 22:35 ` no-reply

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=d81b626f-25a0-7f88-9788-a44b6a6222ee@redhat.com \
    --to=mreitz@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.