|
|
1.1 ! root 1: This file documents the TURBO_DISK changes made by Tim Howes at the University ! 2: of Michigan. ! 3: ! 4: 1. Overview: ! 5: ! 6: The TURBO_DISK option is designed to make updates to the quipu x.500 ! 7: database much faster. Normally when an entry is modified, quipu writes to ! 8: disk the entire edb file containing that entry. If the edb file is at all ! 9: large, this can take quite some time. The TURBO_DISK changes keep the disk ! 10: data in dbm files (actually gdbm files) instead of regular edb files. This ! 11: way, when an update is made only the affected entry need be rewritten. ! 12: ! 13: The performance increase you experience will be directly proportional to ! 14: the size of your edb files. Whereas an update operation used to take time ! 15: proportional to the size of the edb file, with TURBO_DISK it takes constant ! 16: time. ! 17: ! 18: 2. Using TURBO_DISK: ! 19: ! 20: First, you'll need a copy of gdbm on your system. Gdbm-1.3 or later is ! 21: recommended. Second, you'll need to make one small change to the file ! 22: turbo_load.c, if you are using the TURBO_LOAD option. The line: ! 23: ! 24: #include "/u/up/tim/src/gdbm-1.3/gdbmdefs.h" ! 25: ! 26: should be changed to reflect the actual location of the gdbmdefs.h ! 27: include file. Note that this file is not installed in the normal process ! 28: of installing gdbm. Disgustingly enough, the turbo_start routine needs ! 29: to be able to stat the gdbm file, so it needs the defs in this file. ! 30: If you are not using the TURBO_LOAD option, this step should not be ! 31: necessary. ! 32: ! 33: Using the TURBO_DISK option involves two steps. First, you must compile ! 34: the dsap library and quipu with the TURBO_DISK option defined. The easiest ! 35: way to do this is to put the following line in ./h/config.h: ! 36: ! 37: #define TURBO_DISK /* enable fast edb update operations */ ! 38: ! 39: You will then need to add ! 40: ! 41: -lgdbm ! 42: ! 43: to the "LSOCKET =" line in config/CONFIG.make. ! 44: ! 45: Then make quipu as usual. The second step involves converting the edb ! 46: file hierarchy into a gdbm file hierarchy. The ./quipu/tools directory ! 47: has some tools to do this for you. The shell script tree2dbm is provided ! 48: for this purpose. Use it like this: ! 49: ! 50: tree2dbm database-directory ! 51: ! 52: where database-directory is the directory where the edb file hierarchy ! 53: begins. This script does a find on that directory for files named EDB ! 54: and runs them through the edb2dbm program which creates a file called ! 55: EDB.gdbm. Alternatively, you can run edb2dbm by hand on each EDB ! 56: file. The original EDB file is neither removed nor molested, so ! 57: you'll need twice the disk space. The up side is that your old edb ! 58: files are still around in case you want to back off to the non-turbo ! 59: quipu. ! 60: ! 61: 3. Other things to note: ! 62: ! 63: With the TURBO_DISK option parse errors will be reported somewhat differently ! 64: in the dsap.log file. Since line numbers don't make much sense in a ! 65: gdbm file, errors will be reported based on the key of the offending ! 66: entry. If you get a parse error (because of a non-printable character, ! 67: for example), the best approach is to do something like this: ! 68: edbcat EDB >bob ! 69: now edit bob and fix the problem ! 70: edb2dbm bob ! 71: mv bob.gdbm EDB.gdbm ! 72: where this procedure assumes you are in the directory containing the ! 73: bad EDB file. The edbcat program can be found in the ./quipu/tools ! 74: 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.