From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54575) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqjHG-0001ov-13 for qemu-devel@nongnu.org; Fri, 08 May 2015 10:29:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YqjH8-0007Sf-UV for qemu-devel@nongnu.org; Fri, 08 May 2015 10:29:21 -0400 Message-ID: <554CC835.80706@redhat.com> Date: Fri, 08 May 2015 08:29:09 -0600 From: Eric Blake MIME-Version: 1.0 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> In-Reply-To: <20150508131432.GO13985@stefanha-thinkpad.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DKBFtQ4tLvIU5IBTJ7LSOex9e4QHKpaxa" 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: Stefan Hajnoczi , John Snow Cc: famz@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com, vsementsov@parallels.com, stefanha@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DKBFtQ4tLvIU5IBTJ7LSOex9e4QHKpaxa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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. >=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 i= n > 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! Is that fatal, though? 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --DKBFtQ4tLvIU5IBTJ7LSOex9e4QHKpaxa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVTMg1AAoJEKeha0olJ0NqepAH/RxlxoX64i+P84kHVJh6yoQ/ cT0B56sjzu0lVInJrqFGybjZqcfoXuS+/Srwwh1pM8EvCiVGTe8vdqIGBmfBktwd NqXaRna6DXfvguWj4FepFePfz+SgQhDimLMxDRNe3SgXGTJyFg3pY3sj4zfo5cgo MUAVPD5NLVqe6d4s8VDWE2KxhuV5vEcJQD2046luKqKo/a6QIPyUovrMfs7F4fvC cZycaDiJRUZr+QX1d7C+VjDd+yxvLXEsbY/YvVxGvEn9+pqKYPMeq2XFO5KJIEgb /v0MZLAYuaK5+w8tzeZxPKMOnrciYalfR63B8Gncx1lGpJ6VpWoPlZkhsks2oUU= =5Nur -----END PGP SIGNATURE----- --DKBFtQ4tLvIU5IBTJ7LSOex9e4QHKpaxa--