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

Re: To remove or not to remove logfiles? (issue #1615)

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-11-26 19:40:38 CET

kfogel@collab.net wrote:

>Berkeley DB 4.2 supports automatic logfile removal. In issue #1615,
>you can read all about how to make it happen. This is technically
>easy, a small matter of programming.
>The question is, which way should be the default -- keep the logfiles,
>or throw them out? (It will be configurable, of course; this is only
>about choosing a default.)
>The argument for throwing them out by default:
> * The repository grows more quickly with the logfiles, and worse,
> the growth is proportional both to the amount of data *and* the
> number of operations done in the repository (including read
> operations, unless I'm totally crazy?).
Not this time. :-) The log files grow proportionally with the amount of
change (data) and the number of BDB transactions created, and we create
those during read-only ops, too.

>The argument for keeping them by default:
> * Brane should make this argument. In the issue, he says: "I also
> suggest against making automatic log file removal the default. We
> should aim for data integrity and recoverability by default. If
> people want to potentially shoot themselves in the foot, we
> should offer the means, but not do it for them."
>Since discussion threads are more productive when not started from a
>position of neutrality :-), I'll add:
>I don't really buy the argument for keeping the logs. Just because
>Berkeley DB happens to offer this incredibly detailed audit and
>recovery trail, doesn't mean we have to take advantage of it.
True...as far as it goes. :-)

>CVS doesn't even support such a thing.
Irrelevant. CVS doesn't support a lot of things we do.

>What are the circumstances where a
>regular backup schedule with 'svnadmin hotcopy' is insufficient and
>one would actually need these space-eating logs?
Bugs in our code that can cause logical corruption of the repository --
that is, at the schema level. If you keep all the log files, you can
roll back (or forward) to a point just before the bug manifested itself.
Otherwise your data could be totally screwed, even when nothing is wrong
with the database files themselves.

>Are such circumstances common enough
They're not common, in fact I don't think it's happened in a released
version yet, but "this is a version control system" and users' data are

>to warrant turning on the space-eating by default?
Given how much emphasis we put on data safety (remember the famous
"we're in alpha, but much more stable than many 1.0's!"), I can't see a
valid reason to turn on log file removal by default. Especially as
switching it off is as simple as passing --bdb-log-autoermove to
"svnadmin create". In fact, the argument against automatic log file
removal is the same as the one against switching off fsyncs by default,
and we provide --bdb-txn-nosync for that.

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 26 19:41:31 2003

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.