From mboxrd@z Thu Jan  1 00:00:00 1970
From: Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: /proc/xen/xenbus supports watch?
Date: Sun, 25 Sep 2005 11:09:43 +1000
Message-ID: <1127610583.796.41.camel@localhost.localdomain>
References: <5d7aca9505090801025f3d5771@mail.gmail.com>
	<3d8eece205090803381b818f18@mail.gmail.com>
	<1126226609.25110.3.camel@localhost.localdomain>
	<3d8eece205091302422ac74f77@mail.gmail.com>
	<1126657264.7896.20.camel@localhost.localdomain>
	<1126689530.4415.10.camel@localhost.localdomain>
	<3d8eece205091405555a2871fc@mail.gmail.com>
	<1126748390.12119.33.camel@localhost.localdomain>
	<aad156145bec3bd706ef69c0e96341a7@cl.cam.ac.uk>
	<1126945564.29203.116.camel@localhost.localdomain>
	<bf4f0a8e8b96fd1ac2701daa78ca52c6@cl.cam.ac.uk>
	<1127088661.23870.47.camel@localhost.localdomain>
	<d7335251fd831e43f944d94e22da3878@cl.cam.ac.uk>
	<1127214064.2656.45.camel@localhost.localdomain>
	<61d8a8d77f6cbe2402b6a05810bd9447@cl.cam.ac.uk>
	<1127355755.7567.24.camel@localhost.localdomain>
	<4f7ac507bdbff3eafe3d0aaba1446e41@cl.cam.ac.uk>
	<1127433079.2722.24.camel@localhost.localdomain>
	<eaf0ac7e
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <eaf0ac7e68e186851be1692632f24472@cl.cam.ac.uk>
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel List <xen-devel@lists.xensource.com>, Steven Hand <steven.hand@cl.cam.ac.uk>, Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
List-Id: xen-devel@lists.xenproject.org

On Fri, 2005-09-23 at 10:24 +0100, Keir Fraser wrote:
> Or is the bundling simply so that you can continue to feed consistent 
> snapshotted values to the transaction from its 'shadow store', even 
> though it is ultimately a doomed transaction?

Yes that was the plan, although see other mail, I now prefer not
allowing save during transactions at all to avoid this issue.

> Do xenstored's performance problems stem from copying the store for 
> every transaction?

Yes.  Using TDB means it's now copying a single file, rather than a
whole directory tree, but if someone puts in enough domains in the store
it will become a problem and we'll need a more sophisticated
implementation.  It would be a fun problem to work on, but I don't think
I can justify spending cycles on it yet: I can create around 10,000
domain-style directories in the store on my laptop in 22 seconds (using
10,000 separate transactions).

The advantage of the "whole copy" approach are simplicity and
robustness: if you SIGKILL xenstored your chances of recovery are
excellent, as commit is done as a rename(2).

Cheers!
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman