fedora-directory-users-request@xxxxxxxxxx wrote:
Date: Fri, 31 Oct 2008 13:41:46 -0400 From: Dan Lannom<dlannom@xxxxxxxxxxxxx>
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/ -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
