Return to TURBO.README CVS log

Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / quipu

BSD 4.3reno

This file documents the TURBO_DISK changes made by Tim Howes at the University
of Michigan.  

1. Overview:

The TURBO_DISK option is designed to make updates to the quipu x.500
database much faster.  Normally when an entry is modified, quipu writes to
disk the entire edb file containing that entry.  If the edb file is at all
large, this can take quite some time.  The TURBO_DISK changes keep the disk
data in dbm files (actually gdbm files) instead of regular edb files.  This
way, when an update is made only the affected entry need be rewritten.

The performance increase you experience will be directly proportional to
the size of your edb files.  Whereas an update operation used to take time
proportional to the size of the edb file, with TURBO_DISK it takes constant
time.

2. Using TURBO_DISK:

First, you'll need a copy of gdbm on your system.  Gdbm-1.3 or later is
recommended.  Second, you'll need to make one small change to the file
turbo_load.c, if you are using the TURBO_LOAD option.  The line:

#include "/u/up/tim/src/gdbm-1.3/gdbmdefs.h"

should be changed to reflect the actual location of the gdbmdefs.h
include file.  Note that this file is not installed in the normal process
of installing gdbm.  Disgustingly enough, the turbo_start routine needs
to be able to stat the gdbm file, so it needs the defs in this file.
If you are not using the TURBO_LOAD option, this step should not be
necessary.

Using the TURBO_DISK option involves two steps.  First, you must compile
the dsap library and quipu with the TURBO_DISK option defined.  The easiest
way to do this is to put the following line in ./h/config.h:

#define TURBO_DISK	/* enable fast edb update operations */

You will then need to add

	-lgdbm

to the "LSOCKET =" line in config/CONFIG.make.

Then make quipu as usual.  The second step involves converting the edb
file hierarchy into a gdbm file hierarchy.  The ./quipu/tools directory
has some tools to do this for you.  The shell script tree2dbm is provided
for this purpose.  Use it like this:

	tree2dbm database-directory

where database-directory is the directory where the edb file hierarchy
begins.  This script does a find on that directory for files named EDB
and runs them through the edb2dbm program which creates a file called
EDB.gdbm.  Alternatively, you can run edb2dbm by hand on each EDB
file.  The original EDB file is neither removed nor molested, so
you'll need twice the disk space.  The up side is that your old edb
files are still around in case you want to back off to the non-turbo
quipu.

3. Other things to note:

With the TURBO_DISK option parse errors will be reported somewhat differently
in the dsap.log file.  Since line numbers don't make much sense in a 
gdbm file, errors will be reported based on the key of the offending
entry.  If you get a parse error (because of a non-printable character,
for example), the best approach is to do something like this:
	edbcat EDB >bob
	now edit bob and fix the problem
	edb2dbm bob
	mv bob.gdbm EDB.gdbm
where this procedure assumes you are in the directory containing the
bad EDB file.  The edbcat program can be found in the ./quipu/tools
directory and is used to convert from gdbm back to plain text format.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.