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

Issue 430

From: Jim Blandy <jimb_at_red-bean.com>
Date: 2002-07-23 00:06:48 CEST

I don't have permission to change any issues, but the "resolution" to
Issue 430 doesn't make sense.

    Duh. svnadmin shouldn't be running db_recover, db_recover should
    be running db_recover. :-) Specifically, run

      $ su svn
      $ cd /usr/www/repositories/svn
      $ /usr/local/BerkeleyDB.3.3/bin/db_recover -e -v
        [... see the happy output ... ]

    (You should probably shut down Apache first, so people don't
    try to access the repository.)

    This reliably recovers repositories that are failing with
    DB_RUNRECOVERY errors in /var/log/httpd/error_log.

According to its description in svn_fs.h, svn_fs_berkeley_recover is
supposed to be perfectly okay for svnadmin to call --- assuming
svnadmin is supposed to be run only when there are no other processes
accessing that repository. If it's not, then there's still something
wrong; this issue shouldn't be closed. I suspect that this has
something to do with the occasional repository hangs, which can be
recovered from by running db_recover in the repository.

The code for the db_recover program is very small: it just parses its
command-line arguments, calls DBENV->open with the right flags, and
then immediately closes that environment. The flags it passes are
almost exactly the same flags that svn_fs_berkeley_recover passes. If
db_recover works, it should be trivial to make svn_fs_berkeley_recover

I'm also wondering about that -e flag to db_recover. From the
documentation, it really sounds as if we shouldn't need to pass it ---
and shouldn't pass it. I suspect that if svn_fs_open_berkeley passed
the DB_CREATE flag, then the -e flag to db_recover would be
unnecessary, and svn_fs_berkeley_recover might start working.

I originally thought the DB_CREATE flag was analogous to the open
system call's O_CREAT and O_TRUNC flags. You certainly want to get an
error if the DB doesn't already exist, and you certainly don't want to
truncate it. But DB_CREATE certainly doesn't mean anything like
O_TRUNC: db_recover always passes it, and that doesn't wipe out our

I think DB_CREATE really means, "Open an environment that nobody else
is operating on right now," whereas the absence of DB_CREATE really
means, "Join an environment that other people are already working in."
So svn_fs_open_berkeley should pass it, because it's sometimes used in
the former context, and it's harmless to pass it in the latter.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 23 00:07:15 2002

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

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