What version of BerkeleyDB did you have before, and what version did you
upgrade to?
I ran this on each instance to get the different version information:
- gunwin32 od.exe on the highest log file
- svnserve.exe --version
Before the upgrade:
svnserve, version 1.1.4 (r13838)
compiled Apr 3 2005, 22:02:31
Size File
46,753,641 log.0000000986
4,825,882,624 strings
Reports (0x00000008), the 4.2 BDB
F:\Backup>od -j12 -N8 -tx4 log.0000000986
0000014 00040988 00000008
0000024
After the upgrade:
svnversion, version 1.2.0 (r14790)
compiled May 22 2005, 22:40:26
Size File
8,388,608 log.0000000999
4,896,718,848 strings
Reports (0x0000000a), the 4.3 BDB
F:\repos\Art_1\db>od -j12 -N8 -tx4 log.0000000999
0000014 00040988 0000000a
0000024
Instead of 'svnadmin recover', have you tried using Berkeley's native
'db_recover' utility, passing it the '-c' option, meaning "perform
catastrophic recovery"?
This was a good suggestion, I tried it, but this was the result.
F:\repos\Art_1\db>db_recover.exe -c -v
Finding last valid log LSN: file: 175 offset 7086368
Recovery starting from [174][28]
db_recover: Recovery function for LSN 175 7066018 failed on backward pass
db_recover: PANIC: No such file or directory
db_recover: PANIC: fatal region error detected; run recovery
db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery
F:\repos\Art_1\db>db_recover.exe -V
Sleepycat Software: Berkeley DB 4.3.28: (April 22, 2005)
From here:
At this point, I either have to try creating it new repo again, with Import
( someone's working copy without .svn folders ) or migrate back to DB 4.2 or
even back to SVN
I've already tried hotbackup and also, dump then load. All of these make
progress up till the end and fill before compleation.
Note: I was able to get SVNADMIN verify f:\repos\Art to run just fine. At
one point, after doing this, we could update and commint (once or twice) and
then faild. Trying this again did not help and verify always compleates
successfuly with no errors *strange
Thanks for everyone's help, please keep the suggestions comming. We like the
product and have 6 or our 7 repos converted and running just fine under
1.2.0, just not this 2+ GB one. All of our other upgrades from Oct. 04 have
been fine.
Cheers,
Christopher 'LanThief' Kreager
One of a 'Few Screws Loose, LC'
www.AFSLGames.com <http://www.AFSLGames.com>
-----------------------------------------------------------------------------------------------------------------------------------
On 01 Jul 2005 08:43:45 -0500, kfogel@collab.net <kfogel@collab.net> wrote:
> 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.)
>
--
- lan
Received on Fri Jul 1 18:35:22 2005