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: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-tools] [PATCH] Xenstore mkdir/write implicitly create directories
From: Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Date: Wed, 24 Aug 2005 09:15:26 +0100
Cc: Xen Tools <xen-tools@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 24 Aug 2005 08:16:53 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1124850027.17004.37.camel@xxxxxxxxxxxxxxxxxxxxx>
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> <1124850027.17004.37.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-tools-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
Hi Rusty!

>       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).

Sounds good, although wouldn't it be just as easy (and maybe a little
more flexible) to implement the --init option in a seperate tool?  Unless
it's really dumb and just wipes out the whole store?  I hacked up a small
tool to blow away old backend directories and even something simple like
that was quite awkward to implement in C because of string handling and
memory allocation.  I think at some point we'll definitely need some
kind of garbage collecting tool...

>       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).

Yes, this is currently one of the major draw backs from switching over
to the store.  If xenstored restarts, you lose all the watches and won't
be able to start any more domains because the backends won't notice any
changes anymore.


Xen-tools mailing list