From mboxrd@z Thu Jan  1 00:00:00 1970
From: Brendan Cully <brendan@cs.ubc.ca>
Subject: Re: [PATCH 4 of 4 V5] tools/xl: Remus - Network
 buffering cmdline switch
Date: Thu, 12 Dec 2013 10:55:37 -0800
Message-ID: <20131212185536.GF19792@casa.int.convergent.io>
References: <patchbomb.1384804983@athos.nss.cs.ubc.ca>
	<3c11efb5e8fef9f07027.1384804987@athos.nss.cs.ubc.ca>
	<21139.28368.115580.228571@mariner.uk.xensource.com>
	<CAP8mzPOh7YDoKx9tw=_1y6JEy8Ro=+qz+v3+2Jeq9mrc4F9+eQ@mail.gmail.com>
	<21161.53825.789223.280079@mariner.uk.xensource.com>
	<CAP8mzPOFg_31-1yuiw__sHT5xW0-D7kSKX4MrXdRyybWQSvQjA@mail.gmail.com>
	<20131212184745.GE19792@casa.int.convergent.io>
	<CAP8mzPPn_3afcLFZTD+y4AnprwvS-cS9vi8xADJfkr=b-EeSQg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <CAP8mzPPn_3afcLFZTD+y4AnprwvS-cS9vi8xADJfkr=b-EeSQg@mail.gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Cc: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>
List-Id: xen-devel@lists.xenproject.org

On Thursday, 12 December 2013 at 10:52, Shriram Rajagopalan wrote:
> >
> >
> > > >
> > > > Is Remus actually useable without network buffering ?  I don't think
> > > > we would want to change the default later, and clearly the default
> > > > should be to behave correctly.
> > > >
> > >
> > > It is usable without network buffering. Memory state is preserved on
> > > failover.
> > > On failover, without network buffering, exising network
> > > connectivity (tcp connections) "may" be lost, under some circumstances.
> >
> > uh, wouldn't it be possible to acknowledge client requests whose
> > backing state hasn't been replicated? So that on failover the backup
> > might have no memory of a promised it had made? it's more than just
> > tcp resets, isn't it?
> >
> >
> true.. which is why I stated ..
> 
>  > You are right about the fact that for Remus to behave 'correctly', one
> > > needs both network and disk buffering -- the latter being absent is the
> > > reason
> > > Remus in libxl is still experimental.

ah, maybe you meant to leave the quotes off of 'correctly'.

> > >
> > > So, might as well enable network buffering by default, punt if the
> > support
> > > is
> > > missing and suggest that the user invoke Remus without network buffering
> > > (while providing sufficient warnings that the failover may be incomplete)
> > >
> >
> 
> :)