From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfQVf-000649-Br for qemu-devel@nongnu.org; Thu, 23 May 2013 04:04:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UfQVa-0003cz-KW for qemu-devel@nongnu.org; Thu, 23 May 2013 04:04:27 -0400 Received: from mail-wg0-x233.google.com ([2a00:1450:400c:c00::233]:47610) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfQVa-0003cu-EX for qemu-devel@nongnu.org; Thu, 23 May 2013 04:04:22 -0400 Received: by mail-wg0-f51.google.com with SMTP id b12so1777087wgh.18 for ; Thu, 23 May 2013 01:04:21 -0700 (PDT) Date: Thu, 23 May 2013 10:04:17 +0200 From: Stefan Hajnoczi Message-ID: <20130523080417.GC2921@stefanha-thinkpad.redhat.com> References: <519603C1.5060104@redhat.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24E144B8C0207547AD09C467A8259F755859A87E@lisa.maurer-it.com> Subject: Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dietmar Maurer Cc: Kevin Wolf , Fam Zheng , qemu-devel , "imain@redhat.com" , Stefan Hajnoczi , Paolo Bonzini , Wenchao Xia On Wed, May 22, 2013 at 03:34:18PM +0000, Dietmar Maurer wrote: > > That sounds like more work than a persistent dirty bitmap. The advantage is that > > while dirty bitmaps are consumed by a single user, the Merkle tree can be used > > to sync up any number of replicas. > > 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). One disadvantage of Merkle trees is that the client becomes stateful - the client needs to store its own Merkle tree and this requires fancier client-side code. It is also more expensive to update hashes than a dirty bitmap. Not because 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. Therefore you can expect worse guest I/O performance than with a dirty bitmap. I still think it's a cool idea. Making it work well will require a lot more effort than a dirty bitmap. Stefan