From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrnTo-0006VT-6F for qemu-devel@nongnu.org; Mon, 11 May 2015 09:10:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YrnTn-0003h2-3e for qemu-devel@nongnu.org; Mon, 11 May 2015 09:10:44 -0400 Date: Mon, 11 May 2015 14:10:32 +0100 From: Stefan Hajnoczi Message-ID: <20150511131032.GD16270@stefanha-thinkpad.redhat.com> References: <1429747493-24397-1-git-send-email-jsnow@redhat.com> <1429747493-24397-2-git-send-email-jsnow@redhat.com> <20150507145440.GN13985@stefanha-thinkpad.redhat.com> <554B9F52.9020003@redhat.com> <20150508131432.GO13985@stefanha-thinkpad.redhat.com> <554CC835.80706@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mJm6k4Vb/yFcL9ZU" Content-Disposition: inline In-Reply-To: <554CC835.80706@redhat.com> Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v3 01/10] qapi: Add transaction support to block-dirty-bitmap operations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: famz@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com, vsementsov@parallels.com, stefanha@redhat.com, John Snow --mJm6k4Vb/yFcL9ZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 08, 2015 at 08:29:09AM -0600, Eric Blake wrote: > On 05/08/2015 07:14 AM, Stefan Hajnoczi wrote: >=20 > > 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. > >=20 > > The ambiguity is whether "commit the changes" for .commit() means > > "changes take effect" or "discard stashed state, making undo > > impossible". > >=20 > > 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. > >=20 > >> That's going to get hard to maintain as we add more transactions. > >=20 > > Yes, we need to be consistent and stick to one of the interpretations in > > order to guarantee ordering. > >=20 > > Unfortunately, there is already an inconsistency: > >=20 > > 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() > >=20 > > external_snapshot followed by internal_snapshot acts like the reverse > > ordering! >=20 > 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 >=20 > 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 --mJm6k4Vb/yFcL9ZU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVUKpIAAoJEJykq7OBq3PIIb4H/2+Dmglp/W25vFBDvQxuYGur /RBrwsL1Wp8C3l8Eh2WGel1X+Otq6zz+hTJX7KJFdeM+LGcT5m4sZ7dz0ym9Mq/I ZQz22I0XvkgPZpcXfKPEb8Lj/LcVUqOkFliK66QAMlyxTTKQisBjij7M5XYa2GOQ zsW6YTccweTVCwnPk521T/u0sv+wxGkPAlLHesZtPhibdKhPOuVIqed7tBtPBY+u /4o9jQFoQP35BcQ8oKTKbAe6rYQBUQAsYIF/YbsySOHONrC1F0HKgD4+9YNsJ6nn 6Di9qbc5pfGWFlm5VOJ25LmeXqQK1AG6Pf0/I/3CJImCuE57tNSIX4KJBo9En9Y= =bBjl -----END PGP SIGNATURE----- --mJm6k4Vb/yFcL9ZU--