[Date Prev][Date Next]
> [stuff deleted]
> I would rather see our energies turned to making back-bdb2
> a reality. I believe it impertive that we development a
> robust, reliable backend. LDBM doesn't provide a transaction
> model to the server and hence back-ldbm will never be robust
> nor reliable.
> Kurt D. Zeilenga <firstname.lastname@example.org>
> Net Boolean Incorporated <http://www.boolean.net/>
Kurt, I don't know what you have in mind, but my recent experiences
with back-bdb2 (aside from getting it to work) are the following:
1. I have a huge directory that I loaded into it (hundreds of thousands
of objects). Slapadd generated a number of log files in /var/tmp. The
first time, I didn't even notice it was doing this, and filled up the
disk (and failed the load). Perhaps there could be some method of
short-cutting some of the transaction stuff during the initial load --
it's unnecessary and might speed things up quite a bit.
2. Also during the slapadd, I tried to run db_archive, but it claimed
no checkpoints were being made, so it would not offer me a list of
log files to delete. I ended up writing a script to just 'rm -f log.*'
in /var/tmp every minute.
3. I found myself wanting to send directions to the Berkeley db2 database,
but did not find much (any) documentation on any specific directives to
put into slapd.conf that might do this. Things like, pointing it to a
directory for the logfiles.
All the above suggests better documentation, and probably some scripts
or programs to help manage the database. For example, if there were
bdb2-specific directives in the slapd.conf file that pointed the log files
to a particular directory, then we might write wrappers for db commands
(eg. db_checkpoint and db_archive) that parse the slapd.conf and send
the right parameters to the real programs.