From: Eric Blake <eblake@redhat.com>
To: Jeff Cody <jcody@redhat.com>
Cc: kwolf@redhat.com, pbonzini@redhat.com, stefanha@gmail.com,
qemu-devel@nongnu.org, supriyak@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH 2/8] block: add live block commit functionality
Date: Fri, 14 Sep 2012 09:45:02 -0600 [thread overview]
Message-ID: <505350FE.1060402@redhat.com> (raw)
In-Reply-To: <1261b29106dbe3ccd08bac7ce737e67bd5ae8577.1347629357.git.jcody@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]
On 09/14/2012 07:41 AM, Jeff Cody wrote:
> This adds the live commit coroutine. This iteration focuses on the
> commit only below the active layer, and not the active layer itself.
>
> The behaviour is similar to block streaming; the sectors are walked
> through, and anything that exists above 'base' is committed back down
> into base. At the end, intermediate images are deleted, and the
> chain stitched together. Images are restored to their original open
> flags upon completion.
>
> +
> +enum {
> + /*
> + * Size of data buffer for populating the image file. This should be large
> + * enough to process multiple clusters in a single call, so that populating
> + * contiguous regions of the image is efficient.
> + */
> + COMMIT_BUFFER_SIZE = 512 * 1024, /* in bytes */
I'm guessing you will add a followup patch that depends on Paolo's
series for controlling the granularity of this buffer? Or is it less
important for the commit case?
> +
> +static void coroutine_fn commit_run(void *opaque)
> +{
> + ret = base_len = bdrv_getlength(base);
> + if (base_len < 0) {
> + goto exit_restore_reopen;
> + }
> +
> + if (base_len < s->common.len) {
> + ret = bdrv_truncate(base, s->common.len);
> + if (ret) {
> + goto exit_restore_reopen;
> + }
> + }
Question: is it valid to have a qcow2 file whose size is smaller than
it's backing image? Suppose I have base[1M] <- mid[2M] <- top[3M] <-
active[3M], and request to commit top into base. This bdrv_truncate()
means I will now have:
base[3M] <- mid[2M] <- top[3M] <- active[3M].
If I then abort the commit operation at this point, then we have the
situation of 'mid' reporting a smaller size than 'base' - which may make
'mid' invalid. And even if it is valid, what happens if I now request
to commit 'mid' into 'base', but 'base' already had data written past
the 2M mark before I aborted the first operation?
I'm worried that you may have to bdrv_truncate() the entire chain to
keep it consistent, which is more complex because it requires more r/w
files.
--
Eric Blake eblake@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 617 bytes --]
next prev parent reply other threads:[~2012-09-14 15:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-14 13:41 [Qemu-devel] [PATCH 0/8] Live block commit Jeff Cody
2012-09-14 13:41 ` [Qemu-devel] [PATCH 1/8] block: add support functions for live commit, to find and delete images Jeff Cody
2012-09-14 15:23 ` Eric Blake
2012-09-14 15:39 ` Jeff Cody
2012-09-14 13:41 ` [Qemu-devel] [PATCH 2/8] block: add live block commit functionality Jeff Cody
2012-09-14 15:45 ` Eric Blake [this message]
2012-09-14 16:07 ` Jeff Cody
2012-09-14 18:23 ` Eric Blake
2012-09-14 20:29 ` Jeff Cody
2012-09-14 13:41 ` [Qemu-devel] [PATCH 3/8] blockdev: rename block_stream_cb to a generic block_job_cb Jeff Cody
2012-09-14 13:41 ` [Qemu-devel] [PATCH 4/8] qerror: new error for live block commit, QERR_TOP_NOT_FOUND Jeff Cody
2012-09-14 16:01 ` Eric Blake
2012-09-14 13:41 ` [Qemu-devel] [PATCH 5/8] block: helper function, to find the base image of a chain Jeff Cody
2012-09-14 13:41 ` [Qemu-devel] [PATCH 6/8] QAPI: add command for live block commit, 'block-commit' Jeff Cody
2012-09-15 1:05 ` Eric Blake
2012-09-15 2:42 ` Jeff Cody
2012-09-14 13:41 ` [Qemu-devel] [PATCH 7/8] qemu-iotests: add initial tests for live block commit Jeff Cody
2012-09-14 13:41 ` [Qemu-devel] [PATCH 8/8] block: after creating a live snapshot, make old image read-only Jeff Cody
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=505350FE.1060402@redhat.com \
--to=eblake@redhat.com \
--cc=jcody@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=supriyak@linux.vnet.ibm.com \
/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.