Zachary Pincus <zpincus@stanford.edu> writes:
> 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.
You're getting into BDB implementation details. BDB is allowed to
store data anywhere it wants, as long as it doesn't lose it. If the
way it guarantees things is by storing stuff in logfiles, then that's
fine -- if you remove a logfile, that's kind of like removing a data
file, then :-).
> 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!
The BDB code and docs filtered through me would be a poor informant
indeed, so I recommend seeing them instead.
---------------------------------------------------------------------
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:41:51 2005