You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Josh Armantrout <jo...@armantrout.us> on 2004/07/14 09:14:40 UTC
SVN repositry wedged and recover command throws error
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">Hi All,<br>
<br>
</font></font><font size="-1"><font face="Helvetica, Arial, sans-serif">I
installed SVN 1.0.5 on Win XP PRO last month and configured SVNServe to
run as a service. I then created a repository and have been using
TortoiseSVN (FWIW the version compiled to use the VS.NET-safe _svn
folders) to commit my changes nightly. Yesterday I committed the
changes from one folder without trouble, but when I went to commit
changes from another folder it came back saying that it couldn't
connect. After rebooting and trying again, an error mentioning a
BerkleyDB file and disk space was displayed (I didn't save it, is there
a log file?). I should also mention that the repository is on a 200GB
disk with 165GB free, so it's clearly not out of space. Now, when I try
to view the repository through the RepoBrowser the browser locks up. If
I try to view it using SVNLook.exe that also locks up. Reading the
documentation, I see that it is likely "wedged", but when running the
suggested<big> </big>"</font></font><font
face="Helvetica, Arial, sans-serif"><span class="command"><small>svnadmin
recover"</small> </span></font><small><span class="command"><font
face="Helvetica, Arial, sans-serif">command I get the following:</font></span></small><br>
<small><span class="command"><font face="Helvetica, Arial, sans-serif"></font></span></small>
<blockquote><small><span class="command"><font
face="Helvetica, Arial, sans-serif">C:\Program
Files\Subversion\bin>svnadmin recover f:\svn\repository</font></span></small><br>
<small><span class="command"><font face="Helvetica, Arial, sans-serif">Please
wait; recovering the repository may take some time...</font></span></small><br>
<small><span class="command"><font face="Helvetica, Arial, sans-serif">svn:
DB_RUNRECOVERY: Fatal error, run database recovery</font></span></small><br>
<small><span class="command"></span></small></blockquote>
<small><span class="command"></span></small><font size="-1"><font
face="Helvetica, Arial, sans-serif">At that point the SVN book asks
for me to send this email to you here, and I can't find any mention of
this database recovery. Can anyone point me in the right direction? I
do have weekly backups of the repository, and the most recent changes
that I was checking in, but my main concern is that I understand what
happened, how to fix it, and how to prevent it from happening in the
future. As we start to get further into our project, we need to be sure
that we can trust SVN to stick with us.<br>
<br>
Thanks,<br>
<br>
--Josh<br>
<br>
</font></font>
</body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN repositry wedged and recover command throws error
Posted by Josh Armantrout <jo...@armantrout.us>.
Oops, sorry :).
--Josh
kfogel@collab.net wrote:
>Josh,
>
>Is there any way you can set your mailer to send plaintext instead of
>HTML mail? The former would be easier for some of us to read (and I
>doubt it would be harder for anyone).
>
>No big deal if not, just asking.
>
>Thanks,
>-Karl
>
>Josh Armantrout <jo...@armantrout.us> writes:
>
>
>><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>><html>
>><head>
>> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
>> <title></title>
>></head>
>><body bgcolor="#ffffff" text="#000000">
>><font size="-1"><font face="Helvetica, Arial, sans-serif">Hi Ben,<br>
>><br>
>>I do have backups, I'm just more concerned about keeping things
>>reliable.<br>
>><br>
>>I was running SVN v1.05, which I understand uses BerkleyDB 4.2, and I
>>downloaded the 4.2 tools.<br>
>><br>
>> --Josh<br>
>><br>
>><br>
>></font></font><br>
>>Ben Collins-Sussman wrote:<br>
>><blockquote cite="mid1089836054.14123.78.camel@localhost.localdomain"
>> type="cite">
>> <pre wrap="">On Wed, 2004-07-14 at 14:11, Josh Armantrout wrote:
>> </pre>
>> <blockquote type="cite">
>> <pre wrap="">Hi Ben,
>>
>>Ok, I downloaded the db tools and after running the recovery received
>>the following:
>>
>> F:\SVN\db4-win32\bin>db_recover -vec -h f:\svn\repository\db
>> db_recover: Finding last valid log LSN: file: 752 offset
>> 339806
>> db_recover: Ignoring log file:
>> f:\svn\repository\db\log.0000000747: magic number
>> 0, not 40988
>> db_recover: Invalid log file: log.0000000747: Invalid argument
>> db_recover: First log record not found
>> db_recover: PANIC: Invalid argument
>> db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run
>> database recovery
>> </pre>
>> </blockquote>
>> <pre wrap=""><!---->
>>
>>Question 1: you *do* have backups, right? :-)
>>
>>Question 2: what version of BDB was your repository using? What
>>version of the tools did you download? The 'invalid argument' thing
>>looks suspicious to me, like a version mismatch.
>>
>>
>>
>> </pre>
>></blockquote>
>></body>
>></html>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN repositry wedged and recover command throws error
Posted by kf...@collab.net.
Josh,
Is there any way you can set your mailer to send plaintext instead of
HTML mail? The former would be easier for some of us to read (and I
doubt it would be harder for anyone).
No big deal if not, just asking.
Thanks,
-Karl
Josh Armantrout <jo...@armantrout.us> writes:
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
> <title></title>
> </head>
> <body bgcolor="#ffffff" text="#000000">
> <font size="-1"><font face="Helvetica, Arial, sans-serif">Hi Ben,<br>
> <br>
> I do have backups, I'm just more concerned about keeping things
> reliable.<br>
> <br>
> I was running SVN v1.05, which I understand uses BerkleyDB 4.2, and I
> downloaded the 4.2 tools.<br>
> <br>
> --Josh<br>
> <br>
> <br>
> </font></font><br>
> Ben Collins-Sussman wrote:<br>
> <blockquote cite="mid1089836054.14123.78.camel@localhost.localdomain"
> type="cite">
> <pre wrap="">On Wed, 2004-07-14 at 14:11, Josh Armantrout wrote:
> </pre>
> <blockquote type="cite">
> <pre wrap="">Hi Ben,
>
> Ok, I downloaded the db tools and after running the recovery received
> the following:
>
> F:\SVN\db4-win32\bin>db_recover -vec -h f:\svn\repository\db
> db_recover: Finding last valid log LSN: file: 752 offset
> 339806
> db_recover: Ignoring log file:
> f:\svn\repository\db\log.0000000747: magic number
> 0, not 40988
> db_recover: Invalid log file: log.0000000747: Invalid argument
> db_recover: First log record not found
> db_recover: PANIC: Invalid argument
> db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run
> database recovery
> </pre>
> </blockquote>
> <pre wrap=""><!---->
>
> Question 1: you *do* have backups, right? :-)
>
> Question 2: what version of BDB was your repository using? What
> version of the tools did you download? The 'invalid argument' thing
> looks suspicious to me, like a version mismatch.
>
>
>
> </pre>
> </blockquote>
> </body>
> </html>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN repositry wedged and recover command throws error
Posted by Josh Armantrout <jo...@armantrout.us>.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">Hi Ben,<br>
<br>
I do have backups, I'm just more concerned about keeping things
reliable.<br>
<br>
I was running SVN v1.05, which I understand uses BerkleyDB 4.2, and I
downloaded the 4.2 tools.<br>
<br>
--Josh<br>
<br>
<br>
</font></font><br>
Ben Collins-Sussman wrote:<br>
<blockquote cite="mid1089836054.14123.78.camel@localhost.localdomain"
type="cite">
<pre wrap="">On Wed, 2004-07-14 at 14:11, Josh Armantrout wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Ben,
Ok, I downloaded the db tools and after running the recovery received
the following:
F:\SVN\db4-win32\bin>db_recover -vec -h f:\svn\repository\db
db_recover: Finding last valid log LSN: file: 752 offset
339806
db_recover: Ignoring log file:
f:\svn\repository\db\log.0000000747: magic number
0, not 40988
db_recover: Invalid log file: log.0000000747: Invalid argument
db_recover: First log record not found
db_recover: PANIC: Invalid argument
db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run
database recovery
</pre>
</blockquote>
<pre wrap=""><!---->
Question 1: you *do* have backups, right? :-)
Question 2: what version of BDB was your repository using? What
version of the tools did you download? The 'invalid argument' thing
looks suspicious to me, like a version mismatch.
</pre>
</blockquote>
</body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: the dangers of DB_LOG_AUTOREMOVE
Posted by Daniel Berlin <db...@dberlin.org>.
On Jul 16, 2004, at 1:56 PM, Eric Ocean wrote:
>>
>
> I'm really in favor of an SQL back end. In particular, I would like to
> investigate the viability of running Subversion on a replicated DB
> setup. FrontBase is my commercial RDBMS of choice (almost complete
> SQL92 compliance, blazing speed, and awesome tech support).
>
> I may be able to help with such an undertaking, depending on how sales
> do of my next product (scheduled to ship in less than two weeks). I'm
> all for killing off the BDB back end.
>
> If we make an SQL back end, SQLite would also be an option for people
> who didn't want to run a DB server.
sqlite has 16mb row limits. Or at least, it did.
3.0 might solve this, it's not clear.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: the dangers of DB_LOG_AUTOREMOVE
Posted by Eric Ocean <bi...@masterpiece-ag.com>.
On Jul 16, 2004, at 9:14 AM, kfogel@collab.net wrote:
> Greg Hudson <gh...@MIT.EDU> writes:
>> In the long run, I think the answer is to make FSFS the default in 1.2
>> if it seems to work well, and to kill the BDB back end in 2.0 if we've
>> managed to write an SQL back end by that time.
>
> +(1 / sqrt(2)) on making FSFS the default in 1.2.
>
> Don't have any thoughts right now on lifespan of BDB. A lot of
> scalability testing has been done on BDB that hasn't been done on
> FSFS.
>
I'm really in favor of an SQL back end. In particular, I would like to
investigate the viability of running Subversion on a replicated DB
setup. FrontBase is my commercial RDBMS of choice (almost complete
SQL92 compliance, blazing speed, and awesome tech support).
I may be able to help with such an undertaking, depending on how sales
do of my next product (scheduled to ship in less than two weeks). I'm
all for killing off the BDB back end.
If we make an SQL back end, SQLite would also be an option for people
who didn't want to run a DB server.
Regards,
Eric Ocean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: the dangers of DB_LOG_AUTOREMOVE
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> In the long run, I think the answer is to make FSFS the default in 1.2
> if it seems to work well, and to kill the BDB back end in 2.0 if we've
> managed to write an SQL back end by that time.
+(1 / sqrt(2)) on making FSFS the default in 1.2.
Don't have any thoughts right now on lifespan of BDB. A lot of
scalability testing has been done on BDB that hasn't been done on
FSFS.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: the dangers of DB_LOG_AUTOREMOVE
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-07-14 at 16:37, Ben Collins-Sussman wrote:
> I wonder if you're right, here, Eric. Sorry, didn't mean to ignore your
> older comments. The reason we decided to activate LOG_AUTOREMOVE by
> default was because we were getting endless complaints about the
> repository "getting too large" by people who had no idea how to clean
> them out. Correctly dminning a BDB repository is a real barrier to
> entry for so many newbies.
People participating in this thread should be sure to review
http://www.contactor.se/~dast/svn/archive-2003-11/1478.shtml where we
initially decided to turn on this flag by default. Pretty much all the
same arguments were made back then.
I have two remarks to make:
* In theory, removing unused logfiles should not be compromising
db_recover's ability to work. Perhaps "catastrophic" recovery wants to
make use of old logfiles, but really, it's BDB's job to be able to work
robustly while using space proportional to the current data set, not
proportional to the full history of DB operations.
* Our reputation for preservation of data is not really going to be
affected by whether we keep logfiles. Either BDB doesn't crap out, and
we are seen as doing a good job, or it does crap out, and we are seen as
doing a bad job even if there's some magic arcane formula you could use
to fix up your data.
A lot of people seem to be happy with Subversion, leading me to believe
that for the most part, BDB doesn't crap out much in the absence of
permissions problems. But of course, ~every time it does, we find out
about it, so we may get the perspective that it craps out a lot.
In the long run, I think the answer is to make FSFS the default in 1.2
if it seems to work well, and to kill the BDB back end in 2.0 if we've
managed to write an SQL back end by that time.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: the dangers of DB_LOG_AUTOREMOVE
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, July 14, 2004 2:16 PM -0500 kfogel@collab.net wrote:
> An improved backup story (one that is easy, removes the logs, deals
> with >2GB tables, etc) would be ideal, IMHO.
Well, anyone who relies upon a repository that isn't a toy without doing a
regular backup gets what they deserve. All I can say is that 'svnadmin dump'
is your friend - regardless of BDB or FSFS backend.
I trust BDB and FSFS about the same: almost not at all. No insult intended,
but if you don't account for your disk drive dying, you're foolish. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: the dangers of DB_LOG_AUTOREMOVE
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> I wonder if you're right, here, Eric. Sorry, didn't mean to ignore your
> older comments. The reason we decided to activate LOG_AUTOREMOVE by
> default was because we were getting endless complaints about the
> repository "getting too large" by people who had no idea how to clean
> them out. Correctly dminning a BDB repository is a real barrier to
> entry for so many newbies.
>
> There's a convenience/security tradeoff here.
>
> If we were to go back to the old way, where log files aren't
> autoremoved, what would our story to users be? "If you want to be
> perfectly secure, then you should allow your repository to fill up with
> logfiles, do a backup, then remove the unused logs. Automate this
> routine somehow."
>
> What do other developers think? Now that LOG_AUTOREMOVE is turned on,
> we're no longer getting endless complaints about disk space, but instead
> we're getting the occasional complaint about a BDB repository not being
> catastrophically recoverable, because logfiles are missing.
>
> Which path is the lesser of the evils?
An improved backup story (one that is easy, removes the logs, deals
with >2GB tables, etc) would be ideal, IMHO.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: the dangers of DB_LOG_AUTOREMOVE
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Ben Collins-Sussman <su...@collab.net> writes:
> Correctly dminning a BDB repository is a real barrier to entry
> for so many newbies.
Yep, BDB is a serious barrier to entry. Newbies, and at least
many if not most non-newbies, ought to start with FSFS. Some may
claim FSFS is not yet stable, to which i answer neither is BDB in
my experience.
> If we were to go back to the old way, where log files aren't
> autoremoved, what would our story to users be? "If you want to
> be perfectly secure, then you should allow your repository to
> fill up with logfiles, do a backup, then remove the unused
> logs. Automate this routine somehow."
"If you're not prepared to administer BDB, use FSFS"? Maybe only
tell people to use the BDB back-end if they know what they're
doing and want some of its advantages?
> Which path is the lesser of the evils?
False dichotomy :).
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: the dangers of DB_LOG_AUTOREMOVE
Posted by Steve Williams <st...@kromestudios.com>.
Of course, you would have to have periodic log removal in combination with a
regular backup. That's part of administering a server.
Sly
> Considering bdb can corrupt your database if you run out of disk space
> (according to a different thread here), not removing logs by default
> doesn't always lead to that path.
>
> Michael
>
> On Jul 14, 2004, at 3:39 PM, Steve Williams wrote:
>
> >> Which path is the lesser of the evils?
> >
> > The path that has a higher level of data integrity.
> >
> > Sly
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: the dangers of DB_LOG_AUTOREMOVE
Posted by Michael Brouwer <mi...@tlaloc.net>.
Considering bdb can corrupt your database if you run out of disk space
(according to a different thread here), not removing logs by default
doesn't always lead to that path.
Michael
On Jul 14, 2004, at 3:39 PM, Steve Williams wrote:
>> Which path is the lesser of the evils?
>
> The path that has a higher level of data integrity.
>
> Sly
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: the dangers of DB_LOG_AUTOREMOVE
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Thu, 15 Jul 2004, Steve Williams wrote:
> > Which path is the lesser of the evils?
>
> The path that has a higher level of data integrity.
>
Yes, what Steve said. I would much rather try to explain how a user can
keep their REPO from growing rather than try to explain that they lost
their data. :-(
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: the dangers of DB_LOG_AUTOREMOVE
Posted by Steve Williams <st...@kromestudios.com>.
> Which path is the lesser of the evils?
The path that has a higher level of data integrity.
Sly
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
the dangers of DB_LOG_AUTOREMOVE
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-07-14 at 15:25, Eric Ocean wrote:
> On Jul 14, 2004, at 1:14 PM, Ben Collins-Sussman wrote:
>
> > On Wed, 2004-07-14 at 14:11, Josh Armantrout wrote:
> >> Hi Ben,
> >>
> >> Ok, I downloaded the db tools and after running the recovery received
> >> the following:
> >>
> >> F:\SVN\db4-win32\bin>db_recover -vec -h f:\svn\repository\db
> >> db_recover: Finding last valid log LSN: file: 752 offset
> >> 339806
> >> db_recover: Ignoring log file:
> >> f:\svn\repository\db\log.0000000747: magic number
> >> 0, not 40988
> >> db_recover: Invalid log file: log.0000000747: Invalid argument
> >> db_recover: First log record not found
> >> db_recover: PANIC: Invalid argument
> >> db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run
> >> database recovery
> >
> >
> > Question 1: you *do* have backups, right? :-)
>
> That's what log files are for between backups. I wrote a while back
> that removing log files by default is a Bad Thing™, but received no
> response. I lost my first repository the same way. I was at the two
> week point, ready to do my first backup when it died.
>
> Anyway, without backups, Josh's repository is hosed. Josh: next time,
> go to your DB_CONFIG file in the db directory of your repository, and
> comment out the line
>
> set_flags DB_LOG_AUTOREMOVE
>
> Ben, since you're one of the core developers, consider his situation
> (and mine) as more evidence that the above line should be commented out
> by default. I'd like to see this changed as part of 1.1.0.
>
> Having a repository be so brittle by default is hurting Subversion's
> image as a reliable source code repository.
>
I wonder if you're right, here, Eric. Sorry, didn't mean to ignore your
older comments. The reason we decided to activate LOG_AUTOREMOVE by
default was because we were getting endless complaints about the
repository "getting too large" by people who had no idea how to clean
them out. Correctly dminning a BDB repository is a real barrier to
entry for so many newbies.
There's a convenience/security tradeoff here.
If we were to go back to the old way, where log files aren't
autoremoved, what would our story to users be? "If you want to be
perfectly secure, then you should allow your repository to fill up with
logfiles, do a backup, then remove the unused logs. Automate this
routine somehow."
What do other developers think? Now that LOG_AUTOREMOVE is turned on,
we're no longer getting endless complaints about disk space, but instead
we're getting the occasional complaint about a BDB repository not being
catastrophically recoverable, because logfiles are missing.
Which path is the lesser of the evils?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN repositry wedged and recover command throws error
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-07-14 at 14:11, Josh Armantrout wrote:
> Hi Ben,
>
> Ok, I downloaded the db tools and after running the recovery received
> the following:
>
> F:\SVN\db4-win32\bin>db_recover -vec -h f:\svn\repository\db
> db_recover: Finding last valid log LSN: file: 752 offset
> 339806
> db_recover: Ignoring log file:
> f:\svn\repository\db\log.0000000747: magic number
> 0, not 40988
> db_recover: Invalid log file: log.0000000747: Invalid argument
> db_recover: First log record not found
> db_recover: PANIC: Invalid argument
> db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run
> database recovery
Question 1: you *do* have backups, right? :-)
Question 2: what version of BDB was your repository using? What
version of the tools did you download? The 'invalid argument' thing
looks suspicious to me, like a version mismatch.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN repositry wedged and recover command throws error
Posted by Josh Armantrout <jo...@armantrout.us>.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">Hi Ben,<br>
<br>
Ok, I downloaded the db tools and after running the recovery received
the following:<br>
<br>
</font></font>
<blockquote><font size="-1"><font face="Helvetica, Arial, sans-serif">F:\SVN\db4-win32\bin>db_recover
-vec -h f:\svn\repository\db</font></font><br>
<font size="-1"><font face="Helvetica, Arial, sans-serif">db_recover:
Finding last valid log LSN: file: 752 offset 339806</font></font><br>
<font size="-1"><font face="Helvetica, Arial, sans-serif">db_recover:
Ignoring log file: f:\svn\repository\db\log.0000000747: magic number</font></font><br>
<font size="-1"><font face="Helvetica, Arial, sans-serif"> 0, not
40988</font></font><br>
<font size="-1"><font face="Helvetica, Arial, sans-serif">db_recover:
Invalid log file: log.0000000747: Invalid argument</font></font><br>
<font size="-1"><font face="Helvetica, Arial, sans-serif">db_recover:
First log record not found</font></font><br>
<font size="-1"><font face="Helvetica, Arial, sans-serif">db_recover:
PANIC: Invalid argument</font></font><br>
<font size="-1"><font face="Helvetica, Arial, sans-serif">db_recover:
DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery</font></font><br>
</blockquote>
<font size="-1"><font face="Helvetica, Arial, sans-serif"><br>
--Josh<br>
<br>
</font></font><br>
Ben Collins-Sussman wrote:<br>
<blockquote cite="mid1089829736.14123.68.camel@localhost.localdomain"
type="cite">
<pre wrap="">On Wed, 2004-07-14 at 13:13, Josh Armantrout wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Ben,
Thank you for such a quick answer. I'm having trouble running the
recovery as I'm not sure where or how you mean to run it. I don't have
a db_recover file in my installation, and the svnadmin recover won't
accept a -c flag. I must apologize that my command line skills are
pretty much nill, but could you clarify how to run the catastrophic
recovery?
</pre>
</blockquote>
<pre wrap=""><!---->
[keeping this on the list]
Grab some BDB tools for win32. I think they're here:
<a class="moz-txt-link-freetext" href="http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=688">http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=688</a>
Grab the 4.2 tools.
</pre>
</blockquote>
</body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN repositry wedged and recover command throws error
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-07-14 at 13:13, Josh Armantrout wrote:
> Hi Ben,
>
> Thank you for such a quick answer. I'm having trouble running the
> recovery as I'm not sure where or how you mean to run it. I don't have
> a db_recover file in my installation, and the svnadmin recover won't
> accept a -c flag. I must apologize that my command line skills are
> pretty much nill, but could you clarify how to run the catastrophic
> recovery?
[keeping this on the list]
Grab some BDB tools for win32. I think they're here:
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=688
Grab the 4.2 tools.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN repositry wedged and recover command throws error
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-07-14 at 04:14, Josh Armantrout wrote:
> C:\Program Files\Subversion\bin>svnadmin recover
> f:\svn\repository
> Please wait; recovering the repository may take some time...
> svn: DB_RUNRECOVERY: Fatal error, run database recovery
Try running catastrophic recovery with the -c flag to the db_recover
tool:
$ db_recover -vec -h f:\svn\repository\db
> , but my main concern is that I understand what happened, how to fix
> it, and how to prevent it from happening in the future.
Here's a FAQ about why the repos may have become 'wedged':
http://subversion.tigris.org/project_faq.html#stuck-bdb-repos
Did anything else change recently? Like, have repository permissions
changed? Did svnserve crash while it had the database open?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org