Re: [Xen-devel] Remus and blktap2

[Shriram Rajagopalan <rshriram@xxxxxxxxx>]

I tried to upstream the DRBD code few years ago, but the maintainers were not willing to accept the patch, stating that stating that I had not proved that the entire Remus system implementation (memory and disk replication) was tolerant to all forms of system errors and maintain consistency of the disk.
Not sure why this mattered to them, as the checkpoint based disk replication protocol could be used independent of Remus for any other system, just like the way companies like Yelp are using the Remus' plug qdisc for controlling their application interaction with network, without using any other part of Remus. Sigh

The only reason to stick to DRBD is because of its resynchronization capabilities. If that is not needed, a Remus style disk replication can be done using Qemu's disk backends. I am out of sync with the current status of disk backends that Qemu offers and Xen supports. So I apologize in advance for any factual inaccuracies.

On Sat, Apr 23, 2016 at 7:35 AM Pasi Kärkkäinen <pasik@xxxxxx> wrote:

Hi,

On Fri, Apr 22, 2016 at 06:07:46PM +0000, Shriram Rajagopalan wrote:
>    Blktap2 was the first disk backend implementation. I moved Remus to DRBD
>    because it had disk resynchronization support. For eg, when primary fails,
>    backup takes over. When primary comes back online, DRBD would
>    automatically resynchronize new changes from the backup disk to the
>    primary disk and will continue to keep them synchronized.
>    At this stage, you have the option of starting Remus replication from
>    backup to primary, or, migrating the VM back to the primary host and doing
>    the primary to backup replication.
>
>    The DRBD support (last I remember) is quite out of date, because the Remus
>    DRBD kernel module I wrote relies on an older kernel version (3.4?) and
>    older DRBD code base (8.1 I think).
>

Are there plans to get the Remus DRBD module upstreamed? Or working with recent DRBD versions?


Thanks,

-- Pasi

--

~shriram

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel