All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Eric Blake <eblake@redhat.com>
Cc: famz@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org,
	mreitz@redhat.com, vsementsov@parallels.com, stefanha@redhat.com,
	John Snow <jsnow@redhat.com>
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v3 01/10] qapi: Add transaction support to block-dirty-bitmap operations
Date: Mon, 11 May 2015 14:10:32 +0100	[thread overview]
Message-ID: <20150511131032.GD16270@stefanha-thinkpad.redhat.com> (raw)
In-Reply-To: <554CC835.80706@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2151 bytes --]

On Fri, May 08, 2015 at 08:29:09AM -0600, Eric Blake wrote:
> On 05/08/2015 07:14 AM, Stefan Hajnoczi wrote:
> 
> > No it doesn't.  Actions have to appear atomic to the qmp_transaction
> > caller.  Both approaches achieve that so they are both correct in
> > isolation.
> > 
> > The ambiguity is whether "commit the changes" for .commit() means
> > "changes take effect" or "discard stashed state, making undo
> > impossible".
> > 
> > I think the "discard stashed state, making undo impossible"
> > interpretation is good because .commit() is not allowed to fail.  That
> > function should only do things that never fail.
> > 
> >> That's going to get hard to maintain as we add more transactions.
> > 
> > Yes, we need to be consistent and stick to one of the interpretations in
> > order to guarantee ordering.
> > 
> > Unfortunately, there is already an inconsistency:
> > 
> > 1. internal_snapshot - snapshot taken in .prepare()
> > 2. external_snapshot - BDS node appended in .commit()
> > 3. drive_backup - block job started in .prepare()
> > 4. blockdev_backup - block job started in .prepare()
> > 
> > external_snapshot followed by internal_snapshot acts like the reverse
> > ordering!
> 
> Is that fatal, though?

Yes, ordering is critical when add-bitmap or clear-bitmap are combined
with drive-backup.  Typically the drive-backup must happen after
add-bitmap or clear-bitmap.

There is probably no one who uses external and internal snapshots
together in a single 'transaction' command, so my example is contrived
but it's the same problem.

> Let's see if I'm understanding the problem
> correctly: if you start with a.qcow2, then
>  external_snapshot followed by internal_snapshot
> should create b.qcow2 then the internal snapshot inside b.qcow2, while
>  internal_snapshot followed by external_snapshot
> should create the internal snapshot inside a.qcow2, then create b.qcow2
> 
> But since we create the BDS node later than the internal snapshot is
> taken, both sequences currently cause the internal snapshot to live in
> a.qcow2.

Right.  Ordering is not honored :(.

Stefan

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2015-05-11 13:10 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-23  0:04 [Qemu-devel] [PATCH v3 00/10] block: incremental backup transactions John Snow
2015-04-23  0:04 ` [Qemu-devel] [PATCH v3 01/10] qapi: Add transaction support to block-dirty-bitmap operations John Snow
2015-04-23  2:22   ` Eric Blake
2015-05-07 14:54   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-05-07 17:22     ` John Snow
2015-05-08 13:14       ` Stefan Hajnoczi
2015-05-08 13:17         ` Max Reitz
2015-05-08 16:19           ` John Snow
2015-05-08 14:29         ` Eric Blake
2015-05-11 13:10           ` Stefan Hajnoczi [this message]
2015-05-18 15:03             ` Kevin Wolf
2015-04-23  0:04 ` [Qemu-devel] [PATCH v3 02/10] iotests: add transactional incremental backup test John Snow
2015-04-23 15:30   ` Max Reitz
2015-05-11 13:54   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-04-23  0:04 ` [Qemu-devel] [PATCH v3 03/10] block: rename BlkTransactionState and BdrvActionOps John Snow
2015-05-18 12:23   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-04-23  0:04 ` [Qemu-devel] [PATCH v3 04/10] block: re-add BlkTransactionState John Snow
2015-04-23  0:04 ` [Qemu-devel] [PATCH v3 05/10] block: add transactional callbacks feature John Snow
2015-04-23 15:32   ` Max Reitz
2015-04-23  0:04 ` [Qemu-devel] [PATCH v3 06/10] block: add refcount to Job object John Snow
2015-04-23  0:04 ` [Qemu-devel] [PATCH v3 07/10] block: add delayed bitmap successor cleanup John Snow
2015-04-23  0:04 ` [Qemu-devel] [PATCH v3 08/10] qmp: Add an implementation wrapper for qmp_drive_backup John Snow
2015-04-23 15:38   ` Max Reitz
2015-04-23  0:04 ` [Qemu-devel] [PATCH v3 09/10] block: drive_backup transaction callback support John Snow
2015-04-23 15:46   ` Max Reitz
2015-04-23  0:04 ` [Qemu-devel] [PATCH v3 10/10] iotests: 124 - transactional failure test John Snow
2015-04-23 16:06   ` Max Reitz

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=20150511131032.GD16270@stefanha-thinkpad.redhat.com \
    --to=stefanha@gmail.com \
    --cc=eblake@redhat.com \
    --cc=famz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@parallels.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.