On Friday 01 July 2005 21:17, firstname.lastname@example.org wrote:
> > 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! :-)
To me, this explanation does not sound convincing. Maybe my understanding of
databases is a bit naive, but shouldn't a serious db that uses transactions
(and a believe bdb uses them) write a transaction first and only then set a
bit "transaction finished" in a most-possibly-atomic way? In such setting,
during a crash one should only loose the last transaction (which for svn
would mean the last checkin), and end up with the database that is fully
usable and just misses that last portion of data. What is wrong in this
So what makes bdb-using-svn rather sensitive to unanticipated breaks in
processing? Actually, I was always thinking that the only purpose of having a
sophisticated db managment system is to provide higher reliability that a
plain filesystem does, not lower...
Sure, I do not mean to say that the bug is necessarily in the bdb library --
it can be in filesystem, kernel, svn -- anywhere... But what about "defensive
programming" and anticipating the ways in which the system is likely to fail,
so that it fails gracefully? Is it at all possible an a database world? ;)
Also, could this incident be related to Dave Camp's corrupted repositories?
(both on MAC OS 10.3, both with bdb backend, both after power failure...
Visuomeninė organizacija "Atviras Kodas Lietuvai"
P.Vileišio g. 18
tel/fax: (+370-5)-210 40 05
mobilus: (+370-684)-49802, (+370-614)-36366
Received on Sat Jul 2 15:09:34 2005
- application/pgp-signature attachment: stored