Mark Slater wrote:
> I actually don't think Subversion is the culprit... unless for some
> reason it failed to exit in the last commit and kept the database open
> without flushing some of the changes. My hope in posting here is that
> someone has come across a related problem on their own system and
> knows enough about the database system to point me on the path that
> gets the repository working again. The database folks know Berkeley
> DB, but not how Subversion uses it.
> To answer your question, the db_dump -r (or -R) do seem to restore the
> database (at least temporarily), but it fails to restore the
> repository. The fun part is that if I try to run svnadmin verify at
> the end of the following command sequence, I get into a cycle; simply
> trying to verify the repository (with an apparently recovered
> database) causes the nodes table to become corrupted again. I can
> repair it, sure, but it doesn't stay that way.
> $ svnadmin verify ~/SVN_Documents/DB
> * Verified revision 0.
> * Verified revision 1.
> svn: Checksum mismatch on rep '3':
> expected: 4286871d7bb225bda5f931bb91cb3ead
> actual: b54cbed34fb8519f8fa4bb47c1de48ee
> svn: Berkeley DB error while closing 'nodes' database for filesystem
> DB_RUNRECOVERY: Fatal error, run database recovery
That's strange. It looks like the nodes table is physically scrambled in
ways that db_recover can't really fix. "svnadmin verify" doesn't change
anything in the nodes table, for all practical purposes it's the same as
"svnadmin dump". Is it possible that your disk happens to have grown a
bad sector somewhere in the nodes file, or that the volume is full?
> $ db_verify nodes
> db_verify: PANIC: fatal region error detected; run recovery
> $ sudo db_recover -v
> db_recover: Finding last valid log LSN: file: 3 offset 401252
> db_recover: Recovery starting from 
> db_recover: Recovery complete at Sun May 2 02:42:15 2004
> db_recover: Maximum transaction ID 80000008 Recovery checkpoint
> $ db_verify nodes
> I've looked at the output of the db_dump command, and there's no way I
> could edit it.... it's lots and lots of numbers that simply don't mean
> anything to me. Is there any way to know which file is causing the
> specific error (checksum mismatch) from svnadmin verify?
Try db_dump with the -p option; you'll see the contents in printable
format, and you can easily interpret the skels. the last string in the
file or dir skels is the "rep key"; find the one that matches the number
in the checksum mismatch error, and you've found your file. Also look at
which explains the skel format and will help you to understand what
Unfortunately, if the scrambled representation is a delta source, it
will affect other versions of that file.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon May 3 12:27:34 2004