Re: [Xen-devel] [PATCH v16 2/7] remus: introduce remus device

[Shriram Rajagopalan <rshriram@xxxxxxxxx>]

On Fri, Jul 18, 2014 at 12:17 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

On Fri, 2014-07-18 at 12:08 -0400, Shriram Rajagopalan wrote:

> The keyword above is "may". Without network buffering, ongoing TCP
> connections "may" be hung, depending on whether any communication
> happened during the failed checkpoint. Same applies to disk.

That doesn't sound like a good reason to offer this amount of rope to an
innocent user.

> If one can control the network interactions or if the application is
> capable of recovering
> from lost TCP connections (or lost UDP packets for that matter), then
> it stands to benefit
> from no-network buffering as it eliminates the latency overhead
> introduced by buffering every
> packet [ 0.5 x checkpoint-interval + RTT between primary-backup].

Now *this* might be a reason to offer such an option for network
traffic.

But is there an existing real world requirement to support this now or
is this just a theoretical desire? Seems like punting on it for the time
being would let the rest of the series make progress.

Most of the if(netbuf_enabled) {} else {} is an artifact of

whether or not the host system has the correct version of libnl installed.

If autoconf said no, then libxl_nonetbuffer.c would be compiled in, but

the existence (or not) of network buffers had to be checked at various points

in code (in libxl), especially for teardown path.

It seems harder to imagine a case where not replicating a disk would be
tolerable.

Read only root file system, tmpfs based scratch file system?

Its useful to just use memory replication for testing/profiling purposes.

So i think a better alternative would be to have an explicit test flag (-t) followedÂ

by the no-netbuf flag (-n) and/or the no disk buffering flag (-d). ÂUse of a test flagÂ

should be suggestive enough to the innocent user that this invocation is notÂ

meant for production, while flexible enough for someone with knowledge ofÂ

the system to disable network or disk replication for other needs.

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