fedora-directory-users-request at redhat.com wrote:
> Date: Fri, 31 Oct 2008 13:41:46 -0400
> From: Dan Lannom<dlannom at umd.umich.edu>
> I've done exhaustive verification of equality and presence indexes for
> my directory to verify that ldap is working properly so I'm going to
> treat dbverify as buggy for now.
dbverify is certainly not buggy. Most likely you're running on a Little-Endian
machine, and FDS is not canonicalizing its keys into Big-Endian format.
(Instead it must be using a custom key comparison function internally.) Since
dbverify only uses the default key comparison function, it will see the keys
as being out of order (even though they're in correct order according to FDS's
custom function).
> I can't find any pattern in my data to explain what the bug is though.
> 22 of the 45 indexes are affected
> syntaxes are oid,directorystring,ia5string,integer and telephonenumber
> index types are either e,ep,eps or aeps
>
> I'll fill out a bug report later tonight,
>
> Dan Lannom
>
> I wrote in my earlier email:
>> I plan to migrate to fds from SunOne 5.2 and so I want to validate the
>> system.
>> I'm currently running version 1.1.3-2 of the directory on RHEL 5.2.
>>
>> When I do searches against the server everything seems to work fine, but
>> When I run /usr/lib/dirsrv/slapd-{{hostname}}/dbverify, with the
>> server off, it fails with
>> errors like:
>> [28/Oct/2008:10:52:16 -0400] - libdb: Page 4: out-of-order key at entry 2
>> [28/Oct/2008:10:52:16 -0400] - libdb: Page 4: out-of-order key at entry 8
>> [28/Oct/2008:10:52:16 -0400] - libdb: Page 4: out-of-order key at
>> entry 11
>> [28/Oct/2008:10:52:16 -0400] - libdb: Page 4: out-of-order key at
>> entry 14
>> ...
>> [28/Oct/2008:10:52:16 -0400] - libdb:
>> /var/lib/dirsrv/slapd-hume/db/{{SUFFIX}}/{{attribute}}.db4:
>> DB_VERIFY_BAD: Database verification failed
>> [28/Oct/2008:10:52:16 -0400] DB verify - verify failed(-30975):
>> /var/lib/dirsrv/slapd-{{hostname}}/db/userdata/{{attribute}}.db4
>>
>> reindexing does not change anything and I find the same errors for
>> both i386 and x86_64 and the errors are almost identical for the
>> master and the slaves.
>>
>> Since I can find any evidence of the indexes identified as corrupted
>> not working I wonder why dbverify is generating these errors.
>>
>> Thanks for any help,
>>
>> Dan Lannom
>> UM-Dearborn
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
