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

Re: Wedged repositories [#6251]

From: Jim Blandy <jimb_at_red-bean.com>
Date: 2002-07-24 00:15:41 CEST

There are three different problems going on here, and I don't think
we've been careful to keep them all straight. Now that I've thought
it through, I don't think we have anything to ask Keith yet.

First: there's general agreement that the Subversion server can die
while holding memory locks. In general, this doesn't seem avoidable;
I mean, it could get a SEGFAULT anywhere. Since the server does *not*
currently run recovery automatically on startup, as everyone agrees it
should, this results in the next access wedging, waiting for a lock to
be released which no live process is holding. The bug here is that
Subversion never runs recovery.

Second: while living with the above bug, we've found that, although
simply running db_recover without -e should be enough to unwedge the
repository, it's not. You have to pass -e. I suspect this is because
running db_recover without -e deletes all the __db.NNN files (the
shared memory pools). The usual "open a repository" function,
svn_fs_open_berkeley, does not pass the DB_CREATE flag, so Berkeley DB
will return an error when it discovers that the __db.NNN files are
missing; if Subversion passed DB_CREATE, it would create them
silently. So running db_recover without -e actually does, in fact,
unwedge the repository. But it also simultaneously introduces a
different problem, this one manifested by error messages, rather than

Third (and this is the one I think Keith would really like to know
about): there's a comment in subversion/svnadmin/main.c that says:

        /* ### todo: this usually seems to get an error -- namely, that
           the DB needs recovery! Why would that be, when we just
           recovered it? Is it an error to recover a DB that doesn't
           need recovery, perhaps? See issue #430. */
        INT_ERR (svn_fs_berkeley_recover (env_path, pool));

Now, this really shouldn't happen --- svn_fs_berkeley_recover calls
DBENV->open with the DB_RECOVER flag, whose whole purpose is to
recover the database after someone has returned DB_RUN_RECOVERY. If
it returns DB_RUN_RECOVERY itself, it's useless; this is clearly a
Berkeley DB bug. Unfortunately, I've never seen this problem happen.
We have no bug report, just a rumor in a comment.

So, the problems we can reproduce, we think we know the answers to,
and we expect they'll fix the wedging repository problem. And the bug
that is alleged to be in Berkeley DB, we can't reproduce.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 24 00:16:16 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.