Zachary Pincus <firstname.lastname@example.org> writes:
> Sure, deleting a log file is a stupid last ditch idiot thing that I
> tried in a panic. But the fact that it worked may indicate a flaw in
> the logging procedures, and definitely one in the recovery
> procedures. So try to forget how idiotic it was, and focus on what
> this may indicate about db reliability issues.
> Finally, note that this is now at least TWO times that I've been able
> to partially fix an "unrecoverable" svn repository by removing
> corrupted logfiles. Thus, I don't think this is some random,
> unrepeatable fluke thing but possibly an actual issue in BDB or how
> SVN and BDB interact.
Well, yes, I hear what you're saying. If time were infinite, this
would be one route to pursue to find bugs and/or potential
improvements in how BDB and Subversion interact. But an even better
route is for us to be working with Sleepycat on making things less
sensitive to misuse in the first place... and there isn't (for me)
time to do both. Heck, I'm too swamped with other stuff to be even
doing that :-). The Subversion developers really carrying the load
there are Mike Pilato and Branko Čibej.
FWIW, it does not necessarily indicate a design flaw that removing a
supposedly unflushed log file can result in no data loss. Sometimes
bits have to be flipped in weird orders in order to prevent race
conditions, and if things crash at the wrong moment, odd states can
Also keep in mind (and I hate to say this) that a repository that
looks fully recovered could, in fact, have missing or corrupt data in
some subtle way; for example, certain kinds of wonkiness in the
'copies' table would not necessarily cause Subversion to stop working.
So you can't be sure that your recipe succeeded 100%, although I
certainly hope it did!
I realize that all of this is vague and hand-wavy. Diving into the
code takes time; it's easier for both of us to post to the list than
to actually figure out what happened :-). This is one reason
switching to FSFS as the default was a good idea, I think: it's a bit
easier for us to debug.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Jul 2 04:23:17 2005