[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: Christopher Kreager <lanthief_at_gmail.com>
Date: 2005-07-01 22:25:27 CEST

Restoring my backup Crashed....! ( Help )

FAQ: After upgrading to Berkeley DB 4.3, I'm seeing repository errors.
http://subversion.tigris.org/faq.html#bdb43-upgrade

Tried to load my dump file with svnadmin.exe, that I created during the
steps outlined in the FAQ above.
Subversion Repository Administrator blew up when it reached revision 212 out
of 845

AppName: svnadmin.exe AppVer: 1.2.0.14790 ModName: libdb43.dll
ModVer: 4.0.3.27 <http://4.0.3.27> Offset: 0006e4c2

I attached the file windows dumped in my temp directory for someone's
review.

------- Committed revision 212 >>>

<<< Started new transaction, based on original revision 213
 * editing path : Levels/Railway/railwaygroundtexture/railwaygroundsec1.tga
... done.
 * editing path : Levels/Railway/railwaygroundtexture/railwaygroundsec2.tga
... done.
 * editing path : Levels/Railway/railwaygroundtexture/railwaygroundsec3.tga
... done.
 * editing path : Levels/Railway/railwaygroundtexture/railwaygroundsec4.tga
... done.
 * editing path : Levels/Railway/railwaygroundtexture/railwaygroundsec5.tga
... done.
 * editing path : Levels/Railway/railwaygroundtexture/railwaygroundsec6.tga
... done.
 * editing path : Levels/Railway/railwaygroundtexture/railwaygroundsec7.tga
... done.
 * editing path : Levels/Railway/railwaygroundtexture/railwaygroundsec8.tga
... done.
This is were it faild.

Please, someone tell me if I can load this file if I go back to SVN 1.1.4
Our Game Demo release is this July and we need to have revision control
between now and release.

Thanks,

 Christopher 'LanThief' Kreager
One of a 'Few Screws Loose, LC'
www.AFSLGames.com <http://www.afslgames.com/>

On 7/1/05, Christopher Kreager <lanthief@gmail.com> wrote:
>
> 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
>

-- 
- lan


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Received on Fri Jul 1 23:01:12 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.