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
work.
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
data.
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