[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: back-bdb (Was: Back up Berkeley dbb files may cause file corruption)
- To: Marijn Meijles <marijn@bitpit.net>
- Subject: Re: back-bdb (Was: Back up Berkeley dbb files may cause file corruption)
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Date: Sun, 14 Oct 2001 22:49:58 -0700
- Cc: openldap-devel@OpenLDAP.org
- In-reply-to: <20011014180145.B20054@unox.athome.tue.nl>
- References: <5.1.0.14.0.20010925162141.016ac838@127.0.0.1> <5.1.0.14.0.20010925141914.016dac68@127.0.0.1> <002c01c14601$dbd58640$7601a8c0@fiddle.symas.com> <5.1.0.14.0.20010925141914.016dac68@127.0.0.1> <20010926000723.A23231@unox.athome.tue.nl> <5.1.0.14.0.20010925162141.016ac838@127.0.0.1>
At 09:01 AM 2001-10-14, Marijn Meijles wrote:
>You wrote:
>> At 03:07 PM 2001-09-25, Marijn Meijles wrote:
>> >I'm wondering, what needs to be done before back-bdb is finished?
>> >only indexing?
>>
>> No, entry caching is absent. Also, select changes to
>> back-ldbm need to ported to back-bdb. And likely other
>> loose ends...
>>
>entry caching? back-bdb has transactions, so why not leave the caching (and
>locking) to bdb?
I believe entry caching will again prove itself as being
highly effective. The performance balance may have shifted
slightly but this is not due to transactions. In particular,
the conversion from database format to in-memory format should
be significantly less than that in back-ldbm. back-ldbm
uses LDIF in id2entry, back-bdb uses BER. Optimizing
BER and memory management will shift the balance further.
However, it is likely that entry caching will still be
effective. We'll see (by performance analysis).