WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 3 of 4] libxc: provide notification of final chec

To: Ian Campbell <ian.campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 3 of 4] libxc: provide notification of final checkpoint to restore end
From: Brendan Cully <brendan@xxxxxxxxx>
Date: Fri, 3 Sep 2010 12:58:47 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 03 Sep 2010 13:01:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <684cfeffdb1b4bacd736.1283519176@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Mail-followup-to: Ian Campbell <ian.campbell@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
References: <patchbomb.1283519173@xxxxxxxxxxxxxxxxxxxxx> <684cfeffdb1b4bacd736.1283519176@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2010-08-04)
On Friday, 03 September 2010 at 14:06, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@xxxxxxxxxx>
> # Date 1283519033 -3600
> # Node ID 684cfeffdb1b4bacd736bc05ae26211cb91833df
> # Parent  de66ba50997cd8670fceffa7b01b50704f82edc7
> libxc: provide notification of final checkpoint to restore end
> 
> When the restore code sees this notification it will restore the
> currently in-progress checkpoint when it completes.
> 
> This allows the restore end to finish up without waiting for a
> spurious timeout on the receive fd and thereby avoids unnecessary
> error logging in the case of a successful migration or restore.
> 
> In the normal migration or restore case the first checkpoint is always
> the last. For a rolling checkpoint (such as Remus) the notification is
> currently unused but could be used in the future for example to
> provide a controlled failover for reasons other than error
> 
> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

This looks sane and passes basic testing here.

Acked-by: Brendan Cully <brendan@xxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel