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

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

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

On Fri, Jul 18, 2014 at 12:17 PM, Ian Campbell <Ian.Campbell@citrix.com>
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.

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

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

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