[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

the dangers of DB_LOG_AUTOREMOVE

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-07-14 22:37:41 CEST

On Wed, 2004-07-14 at 15:25, Eric Ocean wrote:
> On Jul 14, 2004, at 1:14 PM, Ben Collins-Sussman wrote:
> > On Wed, 2004-07-14 at 14:11, Josh Armantrout wrote:
> >> Hi Ben,
> >>
> >> Ok, I downloaded the db tools and after running the recovery received
> >> the following:
> >>
> >> F:\SVN\db4-win32\bin>db_recover -vec -h f:\svn\repository\db
> >> db_recover: Finding last valid log LSN: file: 752 offset
> >> 339806
> >> db_recover: Ignoring log file:
> >> f:\svn\repository\db\log.0000000747: magic number
> >> 0, not 40988
> >> db_recover: Invalid log file: log.0000000747: Invalid argument
> >> db_recover: First log record not found
> >> db_recover: PANIC: Invalid argument
> >> db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run
> >> database recovery
> >
> >
> > Question 1: you *do* have backups, right? :-)
> That's what log files are for between backups. I wrote a while back
> that removing log files by default is a Bad Thing™, but received no
> response. I lost my first repository the same way. I was at the two
> week point, ready to do my first backup when it died.
> Anyway, without backups, Josh's repository is hosed. Josh: next time,
> go to your DB_CONFIG file in the db directory of your repository, and
> comment out the line
> Ben, since you're one of the core developers, consider his situation
> (and mine) as more evidence that the above line should be commented out
> by default. I'd like to see this changed as part of 1.1.0.
> Having a repository be so brittle by default is hurting Subversion's
> image as a reliable source code repository.

I wonder if you're right, here, Eric. Sorry, didn't mean to ignore your
older comments. The reason we decided to activate LOG_AUTOREMOVE by
default was because we were getting endless complaints about the
repository "getting too large" by people who had no idea how to clean
them out. Correctly dminning a BDB repository is a real barrier to
entry for so many newbies.

There's a convenience/security tradeoff here.

If we were to go back to the old way, where log files aren't
autoremoved, what would our story to users be? "If you want to be
perfectly secure, then you should allow your repository to fill up with
logfiles, do a backup, then remove the unused logs. Automate this
routine somehow."

What do other developers think? Now that LOG_AUTOREMOVE is turned on,
we're no longer getting endless complaints about disk space, but instead
we're getting the occasional complaint about a BDB repository not being
catastrophically recoverable, because logfiles are missing.

Which path is the lesser of the evils?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 14 22:39:12 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.