On Jul 1, 2005, at 1:28 PM, kfogel@collab.net wrote:
> 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 :-).
Granted. But my point here wasn't about removing logfiles! (Please see
my next email.) It was about the lack of tools to roll-back data to a
previous, valid state. The subversion docs make a lot of claims about
how BDB is great to use because if things get munged up, it's easy to
restore the database to a previous working state. For example, from the
subversion book:
> Berkeley DB is also a very reliable database system. Subversion uses
> Berkeley DB's logging facilities, which means that the database first
> writes to on-disk logfiles a description of any modifications it is
> about to make, and then makes the modification itself. This is to
> ensure that if anything goes wrong, the database system can back up to
> a previous checkpoint -- a location in the logfiles known not to be
> corrupt -- and replay transactions until the data is restored to a
> usable state. See the section called Managing Disk Space for more
> about Berkeley DB logfiles.
This is great and all -- *but how do you actually get subversion to
roll the database back to a consistent state?* Sure, svn recover (and
db_recover -c) try to get the database back to the *latest* state. But
if they fail, they throw up their hands and just say "run database
recovery" like that's not what you were just doing. Thus far, it
appears like subversion provides no tools for rolling back a database
that's been corrupted to the last "clean" state (potentially losing a
commit in the process), despite claims of *this very ability* in the
documentation.
It's reasonable that a logfile might get corrupted when the power goes
out. What's unreasonable is a complete lack of tools to roll back a
corrupted log file, beyond (a) totally black-box "recovery" processes
and (b) my stupidly crude method of just deleting the corrupted file to
"roll it back" which is (as you are at pains to point out) not a very
reliable or general solution to the problem.
This problem has happened to me several times. Once with a power
failure, once with a hard system crash (overheated rack), and once
spontaneously. NEVER has the "recovery" procedure worked for me. Yet
every time I read the SVN docs, all I can see is how great BDB is
because the transactions are logged and journaled. When I read that, I
think that this means that if the system crashes **HOURS AFTER** a
successful commit, I should be able to, at the very least, easily get
the database back to a recent and reasonably consistent state.
Zach Pincus
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 2 01:27:57 2005