Re: [Xen-devel] pthread_mutex_lock() and Xenstored

["Peter Teoh" <htmldeveloper@xxxxxxxxx>]

On 9/15/07, Bastian Blank <bastian@xxxxxxxxxxxx> wrote:
> On Sat, Sep 15, 2007 at 02:01:12PM +0800, Peter Teoh wrote:
> >     * does databases need to be shareable across heterogeneous systems
> > by a simple file copy across the network like SAMBA?
>
> Most db files are not interchangable. And the xenstore db is usually
> useless on another system. You want to define your own transfer format
> if you want to do this and not rely on the db to support that.
>
> >     * Can't use thread libraries as they conflict with LWP.
>
> "Library for WWW in Perl"? Even wikipedia does not list a better match.
> pthread is LSB and SUSv3. And with a proper db you can use fork if
> necessary.
>
> >     * identifying the minimal amount of mapping operation needed, and
> > possibly its corresponding hashing structures.
> >     * and finally, to come up with the simplest design that meet all
> > the requirements.
> >
> > Can Dan's CDB be a possible alternative candidate for our database
> > design?   Please enlighten me :-).
>
> Isn't CDB also read-only, aka needs to be rewritten on each write?
> xenstored with tdb does this.
>

Have not the time to look into CDB yet.   More important is to
understand in depth what actually is the requirements of Xenstored -
its basic need for a transaction concept?   ACID properties?   FIFO
queue properties?   Can we consider other alternatives like lock-free
database?   For example:

http://en.wikipedia.org/wiki/Lock-free_and_wait-free_algorithms
http://www.grame.fr/pub/LockFree.pdf

And then there is a concurrency vs performance tradeoffs issue as well
(eg, row-level locking in database usually implies higher overheads in
processing).   So it will be good if lock-free algo are favored.

Another possibility is also batching of transactions, just like
batching of hypercall in Xen, so as to cut down the overheads of
starting and closing the transaction.

> Usually I would say, bdb is a good choice for this usage. Supports
> transactions, multiple reader. It is used by many things with large
> writing frequency.
>

Yes, I agree, bDB is used in MySQL etc.

On 9/15/07, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote:

> I repeated those tests against Xen 3.1 a few months back and the 
> characteristics
> haven't changed all that much. Running further OProfile tests on a debug build
> would confirm this.
>

Any possibility of accessing these data?

> Since it is not possible to ever actually restart xenstored, the easy answer
> is to not use any database on disk at all. Simply keep the entire information
> set in RAM. None of the data is keeps per VM needs to persist once the VM
> shuts down - all the important state is maintained by XenD which does persist.
>

Persistency is traded off here.   I thought if traditional filesystem
can do without the database concept (eg, rollback concept when
non-integrity of data is detected), why not here?

Any comments?   Apologized if I am wrong in any area.

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