Indeed. One would expect that the purpose of a journaled system is
that if one of the transactions is still in a log file when the
system goes down, it can either be re-commited, or the database
should be able to be rolled back to N-1 as it were.
As I recently discovered, that does not seem to be the case with svn
and bdb. A failure in a log file seems to torch the whole database.
In addition, it's not clear why stuff sits in log files beyond the
end of a session. I would expect that when svnserve is done with the
transaction, the changes would be commited to the main database file.
It's not clear to me how the usage of bdb can be considered safe for
use as a backend. And from the feedback I'm getting on my recent
problems, I'm not the only one thinking this.
Just to be clear, I'm not trying to beat anyone up or lay blame for
my recent problems on the svn developers. svn is a great tool and I
appreciate all the hard work that is put into it. But if bdb is not a
solid solution for storing your source code (and recent postings
suggest it's a time bomb) I think the svn developers should make a
concerted effort to get existing users to switch to fsfs.
Dave
On Jul 1, 2005, at 1:07 PM, Zachary Pincus wrote:
> Wait a second... I thought the whole point of using BDB was that it
> was journaled, and that any transaction was thus guaranteed atomic
> and re-playable (if the transaction was a success).
>
> So, (a) how is it that a commit that happened hours before the
> power went down existed *only* in a log file? And (b), is there a
> way to "play back" all of the non-corrupted transactions? That is,
> if transaction N resides only in the (corrupted) log file but
> everything else is properly journaled/whatever, shouldn't it be
> trivial to restore the DB back to state N-1? It seems really
> unfortunate that if a log file gets corrupted, there's no simple
> way to roll the repository back to the last "usable" state, and
> instead you have to rely on questionable database "recovery" steps
> that apparently don't deal super-well deal bungled logfiles.
>
> Further, as I stated, by deleting the logfile, I was able to
> restore (read-only) functionality to the repository -- *all the way
> up to the latest commit*. So it appears that the real problem
> wasn't that the last commit hadn't been flushed from the log to the
> database, but that BDB had somehow forgotten that it had already
> flushed that and thought that the logfile was still somehow active.
> Is this a separate vulnerability in BDB?
>
> Presumably I am missing some subtleties of how the DB functions. As
> such, I'm not trying to be antagonistic with these questions, but
> just trying to reconcile what I know (mostly from the SVN docs,
> which make strong claims about why BDB is great) with what you're
> telling me now. A deeper understanding of the DB would certainly
> help me get things sorted out!
>
> Thanks for your time,
>
> Zach Pincus
>
>
> On Jul 1, 2005, at 11:17 AM, kfogel@collab.net wrote:
>
>
>> Zachary Pincus <zpincus@stanford.edu> writes:
>>
>>> Thanks for putting up this information! Unfortunately, I was never
>>> able to get my original repository fully-recovered. Though, as I
>>> said,
>>> through some miracle I did manage to get it to a state where I could
>>> perform a dump, by playing stupid games with the log files.
>>>
>>> Since power had gone down well *after* the last commit to SVN, the
>>> only thing that seemed to have gotten corrupt was the log files
>>> themselves, and not the db; and it seems (in the few times I've had
>>> this type of problem) that BDB is very sensitive to corrupt log
>>> files
>>> and has difficulty recovering from them.
>>>
>>
>> Well, until a checkpoint happens (i.e., data is sync'd from log file
>> to database file), the logfiles hold the only copy of actual
>> data. So
>> BDB's sensitivity to logfile corruption is understandable! :-)
>>
>> -Karl
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Received on Fri Jul 1 23:36:10 2005