OK, this is a series of three patches. The first introduces a speed
test, which opens a transaction on "/", creates a directory, puts 50
entries in it, and commits the transaction. It does this N times, and
the effect of xenstored using separate files and journalling filesystems
shows: N=100 takes 33 minutes(!) on my laptop, which is a level of
unprecedented suckage.
So the second patch changes over to use a TDB, rather than a directory
hierarchy for storage, and changes transaction semantics. This is much
friendlier for NFS, more compact, and much, much faster. The
transaction implementation is naive: it applies to the whole store, and
if someone has made a change since your transaction started, you get
EAGAIN. We can get clever with merging later. Previously we used a
lock to implement transactions, with deadlock protection by breaking the
lock after one second and returning ETIMEDOUT. Unfortunately, the store
was so slow that we were seeing this (and treating it as a soft error,
which makes it worse, risking livelock), and Christian pointed out that
this model is also flawed in theory: domains can be paused for infinite
duration. So, transaction_end can now fail with EAGAIN at any time: you
have to loop. Sorry, I tried.
The final patch in the series cleans up the callers. Me speak little
python, so watch those parts: I made xstransact.commit() return true or
false, rather than raise an exception, which seems more useful for the
python interface.
Due to size, attached as a "bundle": you should be able to import using
"unbundle". Hope that works!
Signed-off-by: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
out
Description: Text document
_______________________________________________
Xen-tools mailing list
Xen-tools@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-tools
|
Home