From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shriram Rajagopalan Subject: Re: [PATCH v16 2/7] remus: introduce remus device Date: Fri, 18 Jul 2014 12:50:38 -0400 Message-ID: References: <1405406805-1455-1-git-send-email-yanghy@cn.fujitsu.com> <1405406805-1455-3-git-send-email-yanghy@cn.fujitsu.com> <21445.29371.640484.799653@mariner.uk.xensource.com> <53C658F9.3090507@cn.fujitsu.com> <21446.26151.961369.811500@mariner.uk.xensource.com> <53C8F1BC.7030705@cn.fujitsu.com> <21449.11824.616690.772949@mariner.uk.xensource.com> <1405699116.6419.1.camel@kazak.uk.xensource.com> <1405700242.6419.12.camel@kazak.uk.xensource.com> Reply-To: rshriram@cs.ubc.ca Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5404803962994345921==" Return-path: In-Reply-To: <1405700242.6419.12.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Lai Jiangshan , Wen Congyang , Andrew Cooper , Jiang Yunhong , Ian Jackson , "xen-devel@lists.xen.org" , Dong Eddie , Hongyang Yang List-Id: xen-devel@lists.xenproject.org --===============5404803962994345921== Content-Type: multipart/alternative; boundary=047d7b673b48f6e15c04fe7a904e --047d7b673b48f6e15c04fe7a904e Content-Type: text/plain; charset=UTF-8 On Fri, Jul 18, 2014 at 12:17 PM, Ian Campbell 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. --047d7b673b48f6e15c04fe7a904e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 18, 2014 at 12:17 PM, Ian Campbell <Ian.Campbell@citrix.com<= /a>> wrote:
On Fri, 2014-07-18 at 12:08 = -0400, Shriram Rajagopalan wrote:

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

That doesn't sound like a good reason to offer this amount of rop= e 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<= br> > 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 lib= xl_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.


meant for production, while flexible enough for someone with knowledge= of=C2=A0
the system to disable network or disk replication for o= ther needs.

--047d7b673b48f6e15c04fe7a904e-- --===============5404803962994345921== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5404803962994345921==--