From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzNvR-00061p-4H for qemu-devel@nongnu.org; Fri, 12 Dec 2014 05:58:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XzNvH-0008HV-Qf for qemu-devel@nongnu.org; Fri, 12 Dec 2014 05:58:21 -0500 Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:51993) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzNvH-0008HI-Jv for qemu-devel@nongnu.org; Fri, 12 Dec 2014 05:58:11 -0500 Received: by mail-wi0-f170.google.com with SMTP id bs8so4119084wib.1 for ; Fri, 12 Dec 2014 02:58:10 -0800 (PST) Date: Fri, 12 Dec 2014 10:58:07 +0000 From: Stefan Hajnoczi Message-ID: <20141212105807.GB22222@stefanha-thinkpad.redhat.com> References: <1417465816-19345-1-git-send-email-jsnow@redhat.com> <1417465816-19345-8-git-send-email-jsnow@redhat.com> <20141209174401.GH27053@stefanha-thinkpad.redhat.com> <20141210013400.GB4666@ad.nay.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gj572EiMnwbLXET9" Content-Disposition: inline In-Reply-To: <20141210013400.GB4666@ad.nay.redhat.com> Subject: Re: [Qemu-devel] [PATCH v9 07/10] qmp: Add support of "dirty-bitmap" sync mode for drive-backup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: kwolf@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com, vsementsov@parallels.com, stefanha@redhat.com, pbonzini@redhat.com, John Snow --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 10, 2014 at 09:34:00AM +0800, Fam Zheng wrote: > On Tue, 12/09 17:44, Stefan Hajnoczi wrote: > > On Mon, Dec 01, 2014 at 03:30:13PM -0500, John Snow wrote: > > > From: Fam Zheng > > >=20 > > > For "dirty-bitmap" sync mode, the block job will iterate through the > > > given dirty bitmap to decide if a sector needs backup (backup all the > > > dirty clusters and skip clean ones), just as allocation conditions of > > > "top" sync mode. > > >=20 > > > There are two bitmap use modes for sync=3Ddirty-bitmap: > > >=20 > > > - reset: backup job makes a copy of bitmap and resets the original > > > one. > > > - consume: backup job makes the original anonymous (invisible to use= r) > > > and releases it after use. > >=20 > > It's not obvious to me that we need both modes. Can you explain why the > > choice between reset and consume is necessary? >=20 > Reset is used in continuous incremental backup, which is obvious: user can > track the new data that comes after this drive-backup starts. >=20 > Consume is better when user has no intention to use this dirty bitmap > afterward. It comes with more convenience and less overhead: no need to > explicitly free the bitmap, and no need for drive-backup job to copy the = dirty > bitmap. >=20 > Copy shouldn't be too slow if it's just in memory, but it does require > 2x memory anyway. >=20 > Alternatively these can all be implemented with transactions. I'm concerned about how error cases and live migration will be handled. It is important not to lose the contents of the dirty bitmap until backup has completed successfully. If there is an I/O error, what happens? While in error state can QEMU be shut down or can live migration take place? I prefer if we have just one mode that is fully tested and thought through. Stefan --gj572EiMnwbLXET9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUiso/AAoJEJykq7OBq3PI7RUH/RoXGOffnIozQDVIKfcLIg1l kc7aDRhEupLHkjLC5lunUPjigY0BXspH1QeUN5gU8f0C+1gv7X0n79hr5KKiXcBm ORfXKh12ZPC+0HYJHgTzhc6e0Nw1nyhc8uBquC8VC172E2rdozsouYIKSxokjGTY uP8GAnl3ONu6q9jfqVCxbcA4eOS1aty9HAZGOXrr45lCivdAyGXBMQjdCCFIDuhj ttBhZLksYhIZZEwu+IgZTPEsCoYFIAG7rYRH/3Sf2GbAIL49nJTpv2qH4NMcUjuZ /fcxLDrzK/IuxD/gAwKUcg3A16K7CIuEkqdas9nq8td9U3iApm5Vf55qW3THJ4o= =Bq9c -----END PGP SIGNATURE----- --gj572EiMnwbLXET9--