From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:59246)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dietmar@proxmox.com>) id 1UfQdF-0001MB-Al
	for qemu-devel@nongnu.org; Thu, 23 May 2013 04:12:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <dietmar@proxmox.com>) id 1UfQdE-000624-6l
	for qemu-devel@nongnu.org; Thu, 23 May 2013 04:12:17 -0400
Received: from smtp.maurer-it.com ([94.136.31.133]:56299
	helo=proxmox.maurer-it.com) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dietmar@proxmox.com>) id 1UfQdD-000620-W0
	for qemu-devel@nongnu.org; Thu, 23 May 2013 04:12:16 -0400
From: Dietmar Maurer <dietmar@proxmox.com>
Date: Thu, 23 May 2013 08:11:42 +0000
Message-ID: <24E144B8C0207547AD09C467A8259F75585D0E74@lisa.maurer-it.com>
References: <519603C1.5060104@redhat.com>
	<CAJSP0QXNm4Yn0RTkOKOBusMK=HrLbambsoMuJ6W-otXZ=tcJBg@mail.gmail.com>
	<5199CF7F.3060507@redhat.com>
	<20130521073159.GA30951@stefanha-thinkpad.muc.redhat.com>
	<519B309E.6020201@redhat.com>
	<20130521103413.GA19747@stefanha-thinkpad.muc.redhat.com>
	<519B4E31.6040503@redhat.com>
	<24E144B8C0207547AD09C467A8259F75585982FB@lisa.maurer-it.com>
	<20130522134330.GB28600@stefanha-thinkpad.redhat.com>
	<24E144B8C0207547AD09C467A8259F755859A87E@lisa.maurer-it.com>
	<20130523080417.GC2921@stefanha-thinkpad.redhat.com>
In-Reply-To: <20130523080417.GC2921@stefanha-thinkpad.redhat.com>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup
	command
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: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <famz@redhat.com>, qemu-devel <qemu-devel@nongnu.org>, "imain@redhat.com" <imain@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, Wenchao Xia <xiawenc@linux.vnet.ibm.com>

> > I also consider it safer, because you make sure the data exists (using =
hash keys
> like SHA1).
> >
> > I am unsure how you can check if a dirty bitmap contains errors, or is =
out of
> date?
> >
> > Also, you can compare arbitrary Merkle trees, whereas a dirty bitmap is=
 always
> related to a single image.
> > (consider the user remove the latest backup from the backup target).
>=20
> One disadvantage of Merkle trees is that the client becomes stateful - th=
e client
> needs to store its own Merkle tree and this requires fancier client-side =
code.

What 'client' do you talk about here?

But sure, the code gets more complex, and needs considerable amount of RAM
to store the hash keys .
=20
> It is also more expensive to update hashes than a dirty bitmap.  Not beca=
use you
> need to hash data but because a small write (e.g. 1 sector) requires that=
 you
> read the surrounding sectors to recompute a hash for the cluster.  Theref=
ore you
> can expect worse guest I/O performance than with a dirty bitmap.

There is no need to update any hash - You only need to do that on backup - =
in fact, all
those things can be done by the backup driver.
=20
> I still think it's a cool idea.  Making it work well will require a lot m=
ore effort than
> a dirty bitmap.

How do you re-generate a dirty bitmap after a server crash?