From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53775) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv6F0-0006P3-CS for qemu-devel@nongnu.org; Wed, 08 Feb 2012 07:03:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv6Ew-0003o3-UD for qemu-devel@nongnu.org; Wed, 08 Feb 2012 07:03:14 -0500 Received: from mail-lpp01m020-f173.google.com ([209.85.217.173]:64441) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv6Ew-0003nr-Ob for qemu-devel@nongnu.org; Wed, 08 Feb 2012 07:03:10 -0500 Received: by lbbgf7 with SMTP id gf7so226835lbb.4 for ; Wed, 08 Feb 2012 04:03:09 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4F3211D0.3070502@zerto.com> References: <73865e0ce364c40e0eb65ec6b22b819d@mail.gmail.com> <4F31153E.9010205@codemonkey.ws> <4F311839.9030709@redhat.com> <4F311BBA.8000708@codemonkey.ws> <4F312FD3.5020206@zerto.com> <4F3137DB.1040503@redhat.com> <4F3139CE.4040103@zerto.com> <4F314798.8010009@redhat.com> <4F3211D0.3070502@zerto.com> Date: Wed, 8 Feb 2012 12:03:09 +0000 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH] replication agent module List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ori Mamluk Cc: Kevin Wolf , =?UTF-8?B?16rXldee16gg15HXnyDXkNeV16g=?= , =?UTF-8?B?16LXldeT15Mg16fXk9ed?= , dlaor@redhat.com, qemu-devel@nongnu.org, Yair Kuszpet , Paolo Bonzini On Wed, Feb 8, 2012 at 6:10 AM, Ori Mamluk wrote: > On 07/02/2012 17:47, Paolo Bonzini wrote: >> But I'm also starting to wonder whether it would be simpler to use >> existing replication code. =A0DRBD is more feature-rich, and you can use= it >> over loopback or NBD devices (respectively raw and non-raw), and also st= ore >> the replication metadata on a file using the loopback device. Ceph even = has >> a userspace library and support within QEMU. >> > I think there are two immediate problems that drbd poses: > 1. Our replication is not a simple mirror - it maintains history. I.e. yo= u > can recover to any point in time in the last X hours (usually 24) at a > granularity of about 5 seconds. > To be able to do that and keep the replica consistent we need to be notif= ied > for each IO. If you intend to run an unmodified drbd server on the rephub, then it may not be possible to get point-in-time backups. (Although this probably depends since things like btrfs or zfs may allow you to get back to arbitrary transactions or timestamps.) But you could consider drbd as a network protocol and implement your own server which speaks the protocol. Then you can add any functionality you like, just like the case with the proprietary rephub server you mentioned in your patch. So the only difference is that instead of using a new custom protocol the rephub would need to speak the drbd protocol. Stefan