From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpvSm-00041h-4p for qemu-devel@nongnu.org; Wed, 06 May 2015 05:17:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YpvSl-0005Zy-5Y for qemu-devel@nongnu.org; Wed, 06 May 2015 05:17:56 -0400 Date: Wed, 6 May 2015 10:17:46 +0100 From: Stefan Hajnoczi Message-ID: <20150506091746.GB24280@stefanha-thinkpad.redhat.com> References: <5541605C.2090904@redhat.com> <20150505102546.GB3149@stefanha-thinkpad.redhat.com> <5548E805.7090304@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ftEhullJWpWg/VHq" Content-Disposition: inline In-Reply-To: <5548E805.7090304@redhat.com> Subject: Re: [Qemu-devel] [Qemu-block] [RFC] Differential Backups List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: libvir-list@redhat.com, Markus Armbruster , Qemu-block , qemu-devel --ftEhullJWpWg/VHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 05, 2015 at 11:55:49AM -0400, John Snow wrote: > On 05/05/2015 06:25 AM, Stefan Hajnoczi wrote: > >On Wed, Apr 29, 2015 at 06:51:08PM -0400, John Snow wrote: > >>This is a feature that should be very easy to add on top of the existing > >>incremental feature, since it's just a difference in how the bitmap is > >>treated: > >> > >>Incremental > >>- Links to the last incremental (managed by libvirt) > >>- Clears the bitmap after creation > >> > >>Differential: > >>- Links to the last full backup always (managed by libvirt) > >>- Does not clear the bitmap after creation > >> > >>No biggie. > > > >Differential backups can be done using incremental backup functionality > >in QEMU: > > > >The client application points QEMU to the same target repeatedly instead > >of keeping separate incremental backups. > > > >Stefan > > >=20 > Oh, so you're saying: >=20 > [anchor]<--[diff1] >=20 > And then when making a new incremental, we re-use diff1 as a target and > overwrite it so that it becomes: >=20 > [anchor]<--[diff2] >=20 > In effect giving us a differential. >=20 > OK, so it's possible, but we still lose out on some flexibility that a > slightly different mode would provide us, like the ability to keep multip= le > differentials if desired. (Well, I suppose we *can* create those by manua= lly > copying differentials after we create them, but that seems hackier than > necessary.) >=20 > Still, it would be such a paltry few lines of code and introduce no real > complexity to the subsystem, and it might make libvirt's time a little > easier for managing such things. I have CCed Eric Blake and the libvirt mailing list. This is a good time to discuss libvirt requirements for backup APIs. Current work for QEMU 2.4: * QMP command to take incremental backup of guest disks in a single atomic operation * Dirty bitmap persistence across live migration and QEMU restart Eric: Do you have any opinion on a differential backup feature in addition to incremental backup. My thoughts are that QEMU should only copy out changed blocks and let the backup application worry about concepts like incremental vs differential. =46rom a host performance perspective, copying out the same blocks that have already been sent in a previous backup is a waste of I/O bandwidth. Even backup applications that want differential backup may not actually use the QEMU feature for this reason. Regarding the size of the patch, there's a cost to adding the tests, documentation, and commiting to QMP APIs. These costs dwarf the small code change that preserves the dirty bitmap. If there's a concrete requirement for this feature then I'm happy with it, but let's not add bells and whistles just because we can. Stefan --ftEhullJWpWg/VHq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVSdw6AAoJEJykq7OBq3PIa8QH/Ay/gHL6CznUP13kljrg0hjK xH4HLaoDVrF4wGN1+amNi+sHG9wI3BCBoJXBpDvOsnl6q71a5ftSjQD8lzKbAzKz VntJIiaZfZwDqQ6quIoWHy1xsg+rYc5xtK2Szrr6X/ovoZOIqTFGt//HbiJvn9MR ViwwRwR8on5ypbRiZWvhmGP2By3LpFLmF3eI0jxIOG06z77iCd+gcLJFf0ZFQxu3 tv9rQlW6zHxPNVU0ojtKp+UNo3L8U/aTAZGyg4n/cJ1AjfSW9kLvhSzxu8lxUuUX pUj0Jna2Nrld9aaW3FeSv1N6GKulIMy+TzhZP8QefIo4FEcY+zlYHJEmWC7URlQ= =98qt -----END PGP SIGNATURE----- --ftEhullJWpWg/VHq--