Re: [Xen-devel] RFC: Still TODO for 4.2?

[Shriram Rajagopalan <rshriram@xxxxxxxxx>]

On Thu, Jan 19, 2012 at 12:42 PM, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx> wrote:

On Thu, Jan 19, 2012 at 11:00:19AM -0800, Shriram Rajagopalan wrote:
> On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>
> > On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> >>
> >>
> >> I do have a set of initial patches for xl remus. Since the "script="
> >> support doesnt exist for disk configurations (required to support both
> >> DRBD and tapdisk backends).
> >>
> >> So, currently I only have memory checkpointing functionality. No disk
> >> buffering.

Were the disk buffering implemented in kernel? As a dm-* device or
through blktap (which is not maintained)?

Blktap2 - userspace (block-remus.c driver). It just needs a hostname and port
number to replicate disk writes to. The main remus control loop communicates with it
via fifos.

DRBD - kernel module (separate source tree. not the mainline one). And remus communicates
with it via ioctls (so easy in libxl).

The current xl disk specs dont support the script format or such extensions, though which
such parameters could be accepted and supplied to the tapdisk2 module (which in turn
loads block-remus driver).

The DRBD backend is also simple. The block-drbd script (in etc/xen/scripts) does all the drbd vodoo stuff
of setting up the drbd resources.

In the worst case, one could simply use tap2:/dev/drbd1 (where /dev/drbd1 is the device exported

by drbd) and in the libxl code, i could strncmp(disk_name,"/dev/drbd",9) and enable the disk buffering,
leaving the responsibility of manually setting up drbd to the user.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel