On Thu, Oct 12, 2006 at 03:33:28PM +0100, Keir Fraser wrote:
> On 12/10/06 15:16, "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote:
>
> > 1. Why the need for xenstored to be doing any of this I/O in the first
> > place?
> > If the DB needs to be kept on disk at all, it really needs to have a 
> > much
> > saner update/transactional model to only update bits which actually
> > change,
> > rather than re-creating the entire DB on every transaction.
> > But it strikes me that the DB could potentially be kept entirely in
> > memory
> > removing the disk I/O completely. Sure yyou wouldn't be able to restart
> > the daemon then, but even today you can't restart xenstored & expect
> > things
> > to still be working.
>
> We plan to keep transactional state in memory, and commit to tdb only on
> transaction completion. In which case you'll be able to achieve what you
> describe above by keeping the tdb file in a ramdisk. I suspect that'll turn
> out to be unnecessary and once we keep a persistent handle on a single tdb
> file and only update what has changed, we'll find the buffer cache will work
> quite nicely.
Agreed,that sounds like it ought to be able to significantly reduce overhead
without neccessarily needing to go to a purely memory backed storage.
Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| 
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel