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/
Home Products Support Community News


Re: [Xen-tools] [PATCH] Xenstore mkdir/write implicitly create directori

To: Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Subject: Re: [Xen-tools] [PATCH] Xenstore mkdir/write implicitly create directories
From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Date: Wed, 24 Aug 2005 12:20:27 +1000
Cc: Xen Tools <xen-tools@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 24 Aug 2005 02:18:21 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20050823195239.GK21194@xxxxxxxxxxxx>
List-help: <mailto:xen-tools-request@lists.xensource.com?subject=help>
List-id: Xen control tools developers <xen-tools.lists.xensource.com>
List-post: <mailto:xen-tools@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=unsubscribe>
References: <1124613561.12154.5.camel@xxxxxxxxxxxxxxxxxxxxx> <20050823195239.GK21194@xxxxxxxxxxxx>
Sender: xen-tools-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2005-08-23 at 20:52 +0100, Christian Limpach wrote:
> Thanks!

Hi Christian,

        I'm working on making the xenstore init/restart more robust.  My idea
is to introduce a "--init" option which means "blow away any data in the
store, we're starting fresh" for use at boot time, and a "--restart"
which shuts down the old xenstored and gracefully takes over (upgrades).

        Without either flag, the xenstored should only start if there's no
daemon running, as currently.

        Restart is a problem for clients: my plan is to enhance the xs library
to implicitly reconnect, timing out if > 30 seconds or so.  There are
some interesting corner cases here.  For domains, their shared memory
page is persistent, so they don't even notice the daemon restarting.

        The daemon is going to have to remember outstanding transactions,
watches and watch events, and associate them when tools reconnect.
Where possible, these will be stored on disk, so even daemon crashes can
be recovered (as far as possible).

Feedback welcome!
A bad analogy is like a leaky screwdriver -- Richard Braakman

Xen-tools mailing list