From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfBav-0006UP-5r for qemu-devel@nongnu.org; Thu, 14 Jun 2012 11:04:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SfBao-000635-Fl for qemu-devel@nongnu.org; Thu, 14 Jun 2012 11:04:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfBao-00062m-78 for qemu-devel@nongnu.org; Thu, 14 Jun 2012 11:04:14 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5EF4Cex024198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 14 Jun 2012 11:04:12 -0400 Message-ID: <4FD9FD6A.2080702@redhat.com> Date: Thu, 14 Jun 2012 09:04:10 -0600 From: Eric Blake MIME-Version: 1.0 References: <806c66b2f071f03bec0b7d45a71512e394386885.1339617170.git.phrdina@redhat.com> <4FD9D67F.5080505@redhat.com> <4FD9FB83.8050208@redhat.com> In-Reply-To: <4FD9FB83.8050208@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig3F2238FCD2FAF9EEB0493DCB" Subject: Re: [Qemu-devel] [PATCH v2] qapi: converted commit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Hrdina Cc: kwolf@redhat.com, Jeff Cody , qemu-devel@nongnu.org, lcapitulino@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3F2238FCD2FAF9EEB0493DCB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/14/2012 08:56 AM, Pavel Hrdina wrote: > On 06/14/2012 02:18 PM, Eric Blake wrote: >> On 06/14/2012 01:35 AM, Pavel Hrdina wrote: >>> Signed-off-by: Pavel Hrdina >>> --- >>> +++ b/qapi-schema.json >>> @@ -1169,6 +1169,21 @@ >>> { 'command': 'block_resize', 'data': { 'device': 'str', 'size': >>> 'int' }} >>> >>> ## >>> +# @commit >>> +# >>> +# Commit changes to the disk images (if -snapshot is used) or >>> backing files. >>> +# >>> +# @device: the name of the device or the "all" to commit all devices= >>> +# >>> +# Returns: nothing on success >>> +# If @device is not a valid block device, DeviceNotFound >>> +# If a long-running operation is using the device, DeviceIn= Use >>> +# >>> +# Since: 1.2 >>> +## >>> +{ 'command': 'commit', 'data': { 'device': 'str' }} >> Should we use this as an opportunity to make the command more powerful= ? >> For example, integrating this with the 'transaction' command or a bl= ock >> job queried by 'query-block-jobs' to track its progress would be usefu= l. >> Also, suppose I have A<- B<- C. Does 'commit' only do one layer (C >> into B), or all layers (B and C into A)? That argues that we need an >> optional parameter that says how deep to commit (committing C into B >> only to repeat and commit B into A is more time-consuming than directl= y >> committing both B and C into A to start with). When a commit is >> complete, which file is backing the device - is it still C (which >> continues to diverge, but now from the point of the commit) or does qe= mu >> pivot things to have the device now backed by B (and C can be discarde= d, >> particularly true if changes are now going into B which invalidate C).= >=20 > What i find out is that 'commit' will commit changes only from C to B > and qemu continues with C from the new commit point. I couldn't find a > way to commit changes and go back to backing file. This should be > supported by parameter and also as you mention that commit all changes > through all snapshots should be supported by another parameter. > The 'transaction' feature would be nice to have too. Which makes it sound like we're starting to overlap with Jeff's work on 'block-commit'. If 'block-commit' proves to be better all around at doing what we want, do we even need to keep 'commit' in QMP, or would it be okay for HMP only= ? --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig3F2238FCD2FAF9EEB0493DCB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJP2f1rAAoJEKeha0olJ0Nq+JcH/3g8lWZJ3wzOcKhYG4fyK9ir O+FWCc1Mv+OHinWltUx6jHhaanlKM4FHV8jbEbFbvAfzn2iLWnKi2yv+RMdAXaWO sCgFwfFKpzemsFYuXDMP26874uER/wXTKr5ppXh9ekF3OtqAdEfLGeq/CjwbFzr/ /bfjCZNZhWA5SEOgmvT2nxxg2sIhPoOqcTkI18rp/S1b8IcdW+yJe5iQZGstzvqR r+r0KFhnVk10rjNauEzcKhC8zAdgE3HQ+gus5KmCClctcj1mei/U1v1gXV+xoS5t ERxmc7Rpeclnb8V0yFgJzJooNFhdHCDBK7uvnu+JjhcQC4SOOFLzhPjlvKTabWQ= =hh9v -----END PGP SIGNATURE----- --------------enig3F2238FCD2FAF9EEB0493DCB--