Comment 26 for bug 16317

Steve Langasek wrote:
> In 2.2, LDBM is a royal mess; even in 2.1, AIUI, there were too many
> problems to consider it releasable.

I've gone back to my servers, to check exact versions of what I am running.

On my Opteron running a Debian-amd64 Sarge, it seems I stuck with slapd
2.1.30-3, which was awfully broken with BDB, but hasn't seen a single
problem with LDBM. The installed BDB packages are for 4.2.52-17 and
never worked correctly. This is rock solid with 90K user accounts and
35K groups on LDBM, it has been running for 6 months with very
aggressive scripts performing daily updates.

My x86 LDAP server is running slapd 2.1.30-3. BDB is 4.2.52-17 as well.
Identical problems with BDB. Rock solid with LDBM.

> And whereas BDB was unusable in the 2.1 packages, it's reported to be vastly
> improved in 2.2 when using the correct version of libdb.

Steve, do you maintain any slapd's under heavy usage? Is anyone running
2.2 with BDB in production with large trees? How stable is it in real life?

It sounds like a really risky move to drop LDBM support which has been
solid (and faster) for years for a BDB support that has been touted as
stable for one or two years, while having trivial crashes.

Not your fault at all -- but I am starting to lose faith in upstream's
definition of "stable".

> The remaining
> corruption bug that is listed in the BTS as applying to 2.2 has at its root
> a misconfigured server; the bug is still RC because a lack of performance
> tuning shouldn't result in database corruption, but its impact appears to be
> minimal unless your server is in an unusable state anyway.

DB corruption upon missing DB_CONFIG was a BDB bug, *and* starting with
4.3 the BDB people had stated that they had fixed things so that a
missing DB_CONFIG file did not lead to corruption. As you would expect,
the defaults were to be set to safe (if slow/untuned) values.

It should not be happening any more, and if it is, then using BDB sounds
like a mistake.

And, just to clarify, with the 2.1 series of slapd, DB_CONFIG tweaking
reduced the chance of lockups, but didn't remove them at all. In fact,
it was so trivial to get the whole thing locked up that at one point I
had a pair of shellscrips that did it quite reliably if run
concurrently. I'll see if I can find them.

regards,

martin
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
       Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------