[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 4.9 GB Art repo not recovering afert 1.1.4 upgrade to 1.2.0

From: <kfogel_at_collab.net>
Date: 2005-07-01 15:43:45 CEST

Christopher Kreager <lanthief@gmail.com> writes:
> Hello to all, you have a wonderful product that my team has been
> enjoying during our Game development. We started using it from Oct
> 2004 on, but have run into a little bit of a bump on only one of our 7
> repos, which is our largest. So keep in mind that 6 repos are running
> fine, all created in the same way except for the DB_CONFIG file which
> had to be changed once we grew into the GB size range.
>
> Server System specs:
> MS XP Professional Version 2002 Service Pack 2
> 2 procs running 1.73 Ghz AMD MP 2100+
> 1.00 GB of RAM
> 36.2 GB free disk space or the repo drive (F:)
> 2.57 GB free disk space on the OS partition (C:)
> ----
> CPU at 18%
> Memory Free 70%
>
> Running:
> svnversion, version 1.2.0 (r14790)
> compiled May 22 2005, 22:40:26
>
> Client:
> TortoiseSVN client 1.2.0
>
> DB_CONFIG file:
> set_lk_max_locks 2000
> set_lk_max_lockers 2000
> set_lk_max_objects 2000
> set_lg_bsize 2097152
> set_lg_max 8388608
> set_lg_regionmax 262144
> set_cachesize 0 8388608 8
> set_flags DB_LOG_AUTOREMOVE
>
> Problem: (might be my db config)
> We recently moved our 4.9 GB Berkly DB (revisions were up to 845) over
> from SVN 1.1.4 to the new 1.2.0
> Quickly we found that the Berkly DB that is packaged was an upgrade so
> we follow the how-to steps provided on your site, which were very
> helpful.

What version of BerkeleyDB did you have before, and what version did
you upgrade to? (Not that knowing that is likely to help us solve
this mystery, but I'd still like to know.)

> - svnadmin recover
> - we backed up our db
> - svnadmin lest-unused-dblogs
> - deleted what was in the list
> - removed all the __db.00* files
>
> So we were up and running. For a while. Then after a few commits and
> updates we received our first DB_RUNRECOVERY from TortoiseSVN client
> 1.2.0. First time we have ever seen it so I counted us lucky up to
> this point.
>
> Steps taken:
> - Repeated the svnadmin recover.
>
> Server message:
> C:\Python23\Scripts>svnadmin recover f:\repos\Art
> Repository lock acquired.
> Please wait; recovering the repository may take some time...
> svnadmin: DB_RUNRECOVERY: Fatal error, run database recovery
> svnadmin: bdb: Recovery function for LSN 175 7066018 failed on backward pass
> svnadmin: bdb: PANIC: No such file or directory
> svnadmin: bdb: PANIC: fatal region error detected; run recovery
>
> Client error message:
> Error: Commit failed (details follow):
> Error: Berkeley DB error for filesystem F:/repos/Art/db while opening
> environment:
> Error: DB_RUNRECOVERY:
> Error: Fatal error, run database recovery
> Error: bdb: PANIC: fatal region error detected; run recovery
>
> We decided to just cut our losses:
> * Create a new blank repo with TortoiseSVN client 1.2.0
> * Took one fo the guys directories, cleaned out all the .svn folders
> * Imported the directory structure into the new repo.
>
> Few days later, (revisions were up to 15) at size of 2.5 GB, we are in
> the same situation.
>
> We need your help to figure this out. We are a few weeks from
> releasing our Demo PC Game and kind of in a time crunch. Again, love
> the product and look forward to working with you.

Instead of 'svnadmin recover', have you tried using Berkeley's native
'db_recover' utility, passing it the '-c' option, meaning "perform
catastrophic recovery"? Make sure nothing else is accessing the
repository when you do it.

(See http://www.sleepycat.com/docs/utility/db_recover.html.)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 1 16:46:03 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.