Re: RFC: Still TODO for 4.2?

[Shriram Rajagopalan <rshriram@cs.ubc.ca>]

[-- Attachment #1.1: Type: text/plain, Size: 1645 bytes --]

On Thu, Jan 19, 2012 at 12:42 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org>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@citrix.com> 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.

[-- Attachment #1.2: Type: text/html, Size: 2174 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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