[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

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

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.