You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Blair Zajac <bl...@orcaware.com> on 2002/07/26 04:17:34 UTC
Repos won't recover with db_recover
I think the problem yesterday of running 'svnadmin lsrevs' on my repos
and having it run out of memory on the system munched it somehow. I've
had to revert to the last hot-backup.py saved file. Thank you for that
script!
On the munched repos, running 'db_recover -ve -h repos/db' works hard
for a while but never stops and running 'strace -p PID' on it shows this:
select(0, NULL, NULL, NULL, {0, 750000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
I've put a tar.bz2 of the entire repos up at
http://forsale.orcaware.com/svn-orcaware-144-repos.tar.bz2
in case anybody wants to look at it (there's also an Ford Explorer for
sale there too :) ). It contains all the log files for the repository.
Is this something Sleepycat should see?
I accidentally wiped out my __db* files before making this tar, so it
has them from the last hot-backup.py running.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repos won't recover with db_recover
Posted by Blair Zajac <bl...@orcaware.com>.
Blair Zajac wrote:
>
> I think the problem yesterday of running 'svnadmin lsrevs' on my repos
> and having it run out of memory on the system munched it somehow. I've
> had to revert to the last hot-backup.py saved file. Thank you for that
> script!
>
> On the munched repos, running 'db_recover -ve -h repos/db' works hard
> for a while but never stops and running 'strace -p PID' on it shows this:
>
> select(0, NULL, NULL, NULL, {0, 750000}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
Even though we don't require now the -e flag to db_recover, I got a
response back from Sleepycat regarding this bug. The attached patch
for db 4.0.14 fixes this problem. I've run it on my broken repos
and the program completed.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
Re: Repos won't recover with db_recover
Posted by Blair Zajac <bl...@orcaware.com>.
Daniel Berlin wrote:
>
> On Thu, 25 Jul 2002, Blair Zajac wrote:
>
> > I think the problem yesterday of running 'svnadmin lsrevs' on my repos
> > and having it run out of memory on the system munched it somehow. I've
> > had to revert to the last hot-backup.py saved file. Thank you for that
> > script!
> >
> > On the munched repos, running 'db_recover -ve -h repos/db' works hard
> > for a while but never stops and running 'strace -p PID' on it shows this:
> >
> > select(0, NULL, NULL, NULL, {0, 750000}) = 0 (Timeout)
> > select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> > select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> > select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> > select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> > select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> > select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> > select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> > select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> >
> > I've put a tar.bz2 of the entire repos up at
> >
> > http://forsale.orcaware.com/svn-orcaware-144-repos.tar.bz2
> >
> > in case anybody wants to look at it (there's also an Ford Explorer for
> > sale there too :) ). It contains all the log files for the repository.
> > Is this something Sleepycat should see?
>
> Probably.
Thanks. I've emailed them the report. Will let the list know if
they come back with anything.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repos won't recover with db_recover
Posted by Daniel Berlin <d....@verizon.net>.
On Thu, 25 Jul 2002, Blair Zajac wrote:
> I think the problem yesterday of running 'svnadmin lsrevs' on my repos
> and having it run out of memory on the system munched it somehow. I've
> had to revert to the last hot-backup.py saved file. Thank you for that
> script!
>
> On the munched repos, running 'db_recover -ve -h repos/db' works hard
> for a while but never stops and running 'strace -p PID' on it shows this:
>
> select(0, NULL, NULL, NULL, {0, 750000}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
> select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
>
> I've put a tar.bz2 of the entire repos up at
>
> http://forsale.orcaware.com/svn-orcaware-144-repos.tar.bz2
>
> in case anybody wants to look at it (there's also an Ford Explorer for
> sale there too :) ). It contains all the log files for the repository.
> Is this something Sleepycat should see?
Probably.
I've run into similar DB fun with cyrus-imap and db4.
In fact, i got databases db_recover would do that on so often i stopped
using it as the backend.
I know *why* it happens. Somehow, the number of locks is out of whack, so
recover keeps trying to acquire an exclusive lock to be able to do
recovery, but can't, since nothing else will ever decrement the number of
locks.
I suspect they have a fix for it, and it's the bug fix noted in the 4.1.XX
changelog as "Fix a bug in DB->rename and DB->remove method calls could
leak a transaction and its locks."
I figured i'd give it another throw as the cyrus imap mail backend
database when they released this version.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org