From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:49849)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1XyWAO-0001mn-BB
	for qemu-devel@nongnu.org; Tue, 09 Dec 2014 20:34:24 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1XyWAI-0001It-5I
	for qemu-devel@nongnu.org; Tue, 09 Dec 2014 20:34:12 -0500
Received: from mx1.redhat.com ([209.132.183.28]:60786)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1XyWAH-0001Ig-TW
	for qemu-devel@nongnu.org; Tue, 09 Dec 2014 20:34:06 -0500
Date: Wed, 10 Dec 2014 09:34:00 +0800
From: Fam Zheng <famz@redhat.com>
Message-ID: <20141210013400.GB4666@ad.nay.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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20141209174401.GH27053@stefanha-thinkpad.redhat.com>
Subject: Re: [Qemu-devel] [PATCH v9 07/10] qmp: Add support of
 "dirty-bitmap" sync mode for drive-backup
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>
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 <jsnow@redhat.com>

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 <famz@redhat.com>
> > 
> > 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.
> > 
> > There are two bitmap use modes for sync=dirty-bitmap:
> > 
> >  - reset: backup job makes a copy of bitmap and resets the original
> >    one.
> >  - consume: backup job makes the original anonymous (invisible to user)
> >    and releases it after use.
> 
> It's not obvious to me that we need both modes.  Can you explain why the
> choice between reset and consume is necessary?

Reset is used in continuous incremental backup, which is obvious: user can
track the new data that comes after this drive-backup starts.

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.

Copy shouldn't be too slow if it's just in memory, but it does require
2x memory anyway.

Alternatively these can all be implemented with transactions.

Fam