OpenLDAP-2.0.11 and DB 3.2.9 caching problems

["Lawrence, Al (A.D.)" <alawren3@ford.com>]

After applying the fixes to allow 2.0.11 to use DB 3.2.9 I've noticed that when running SLAPADD, only one file (id2entry.dbb - the first opened?) seems to be cached while the others seem to be written out immediately (i.e. not cached). I really need to have cache for all the .dbb files (32 indexes) since I'm processing a 677Meg LDIF that results in about 2.6Gig(1.9Gig for id2entry alone!) of database files. Can anyone find the bug or explain what is happening? I've already contacted Sleepycat but they claimed not to know of any problem like this with environment cache and pointed me here. As I type this I wonder if "env" is being corrupted some how...

The other problem I have is with setting "dbcachesize". I really need to have more than 2Gig of cache (probably more) to avoid the LDIF load from taking forever. The code (ldbm.c) only really allows you to set cache to 1Gig (even though it accepts numbers up to 2 Gig[ 4 if thats an unsigned int]). Sleepycat's documentation says "int DBENV->set_cachesize(DB_ENV *dbenv, u_int32_t gbytes, u_int32_t bytes, int ncache);". Looking at ldbm.c's call to DB's setcachesize method "env->set_cachesize( env, 0, dbcachesize, 0 ); " it only passes dbcachesize in the "bytes of cache". From the documentation that appears to be the number of bytes less that a Gig. The "Gbytes of cache" parm is set to 0. Shouldn't the dbcachesize be divided into the number of Gig's(gbytes) and the remainder(bytes) in the call? Also my architecture  would like to have the cache allocated in chunks instead of one big malloc. DB has a parameter for that "ncache" (they indicate this is necessary for SUN's) which is!
 set to 0 in ldbm.c.  Shouldn't there be a config option like "dbcachechunks" to set that? I've been toying with a fix for this but wondered if anyone else has dealt with this before (why reinvent the wheel?).