Hello, I could reproduce the problem and filed a bug: Summary: dbverify: when a duplicate is large enough to have internal page(s), dbverify issues bogus out-of-order key errors https://bugzilla.redhat.com/show_bug.cgi?id=472131I've also posted a question/bug report to Berkeley DB forum today. If you are interested in, please take a look at the following link.
Posted to the Oracle/Berkeley DB forum: http://forums.oracle.com/forums/thread.jspa?threadID=828256&stqc=true verify reports bogus out-of-order key messages Thanks, --noriko Dan Lannom wrote:
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.I can't find any pattern in my data to explain what the bug is though. 22 of the 45 indexes are affectedsyntaxes 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, butWhen I run /usr/lib/dirsrv/slapd-{{hostname}}/dbverify, with the server off, it fails witherrors 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}}.db4reindexing 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 -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
<<attachment: smime.p7s>>
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
