You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2003/11/26 17:38:53 UTC
To remove or not to remove logfiles? (issue #1615)
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?).
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. CVS
doesn't even support such a thing. What are the circumstances where a
regular backup schedule with 'svnadmin hotcopy' is insufficient and
one would actually need these space-eating logs? Are such
circumstances common enough to warrant turning on the space-eating by
default?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by Branko Čibej <br...@xbc.nu>.
Justin Erenkrantz wrote:
> --On Wednesday, November 26, 2003 19:40:38 +0100 "Branko ?ibej"
> <br...@xbc.nu> wrote:
>
>> 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
>
>
> Without having read the issue (sorry, no web browser handy), will it
> be possible to change this *after* the repository has been created?
>
> Ideally, shouldn't this be in DB_CONFIG or whatnot? -- justin
Yes, it will be in DB_CONFIG. The question is whether we put it there by
default or not.
--
Brane Čibej <br...@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
Re: To remove or not to remove logfiles? (issue #1615)
Posted by kf...@collab.net.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> > 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
>
> Without having read the issue (sorry, no web browser handy), will it
> be possible to change this *after* the repository has been created?
>
> Ideally, shouldn't this be in DB_CONFIG or whatnot? -- justin
Yup, it will -- see Brane's comments in issue #1615 for details.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, November 26, 2003 19:40:38 +0100 "Branko ?ibej"
<br...@xbc.nu> wrote:
> 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
Without having read the issue (sorry, no web browser handy), will it be
possible to change this *after* the repository has been created?
Ideally, shouldn't this be in DB_CONFIG or whatnot? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by Thom May <th...@planetarytramp.net>.
* Branko ??ibej (brane@xbc.nu) wrote :
> kfogel@collab.net wrote:
>
> >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.
>
+1
(The fact I've snipped the rest of the email is for ease of reading, i agree
with everything in the mail).
We should provide the *option* to auto remove logs, certainly. But it should
never be the default.
Cheers
-Thom
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> I don't see why. It's an incredibly trivial change, and off by default.
> _And_ it won't work unless you build with BDB 4.2. Putting it into 0.34
> will at least get it tested by people who only use releases.
(I don't think the BDB 4.2 req't is relevant for this question...?)
Sure, it's a small change, but there's still no reason to rush it in.
It's not like a comment fix or an obvious bugfix, where the risk is
really zero. And we're going to need a 0.35 anyway, for the
auto-deltification changes.
Also, there's still an ongoing discussion of what the default should
be, and it would be nice (though I suppose not strictly necessary) for
that to be settled before this appears in a release.
There's no compelling reason to put this in 0.34, and some reasons not
to. So let's not.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>kfogel@collab.net writes:
>
>
>>>>(Got some internal stuff to take care of first, before I start on this
>>>>& the auto-deltification work, so the commits may be delayed.)
>>>>
>>>>
>>>Um. I can do this in about 15 minutes + "make check" time. Shall I steal
>>>the issue?
>>>
>>>
>>Oh, *bless you*, yes please.
>>
>>
>
>By the way, we shouldn't include this in 0.34 IMHO -- a change like
>this ought to get some soak time.
>
I don't see why. It's an incredibly trivial change, and off by default.
_And_ it won't work unless you build with BDB 4.2. Putting it into 0.34
will at least get it tested by people who only use releases.
--
Brane Čibej <br...@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
Re: To remove or not to remove logfiles? (issue #1615)
Posted by kf...@collab.net.
kfogel@collab.net writes:
> > >(Got some internal stuff to take care of first, before I start on this
> > >& the auto-deltification work, so the commits may be delayed.)
> >
> > Um. I can do this in about 15 minutes + "make check" time. Shall I steal
> > the issue?
>
> Oh, *bless you*, yes please.
By the way, we shouldn't include this in 0.34 IMHO -- a change like
this ought to get some soak time. Not that this matters: it can still
be committed on trunk right now, of course. We'll just tell Jostein
an earlier revision for the release branch (haven't figured out
exactly which one yet, that's part of the other work I was talking
about).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> >(Got some internal stuff to take care of first, before I start on this
> >& the auto-deltification work, so the commits may be delayed.)
>
> Um. I can do this in about 15 minutes + "make check" time. Shall I steal
> the issue?
Oh, *bless you*, yes please.
And ignore the jealousy waves coming from Chicago... (The stuff I have
to do atm isn't coding work).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>Hrm, okay, you convinced me. I'll code it with 'keep' as the default.
>But will add to the FAQ item about repository growth, and to the Book,
>so people can easily find out how to turn this off.
>
>
And to "svnadmin --help" :-)
>(Got some internal stuff to take care of first, before I start on this
>& the auto-deltification work, so the commits may be delayed.)
>
>
Um. I can do this in about 15 minutes + "make check" time. Shall I steal
the issue?
--
Brane Čibej <br...@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
Re: To remove or not to remove logfiles? (issue #1615)
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> 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
> sacred.
>
> >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.
Hrm, okay, you convinced me. I'll code it with 'keep' as the default.
But will add to the FAQ item about repository growth, and to the Book,
so people can easily find out how to turn this off.
(Got some internal stuff to take care of first, before I start on this
& the auto-deltification work, so the commits may be delayed.)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by Branko Čibej <br...@xbc.nu>.
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
sacred.
>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 <br...@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
Re: To remove or not to remove logfiles? (issue #1615)
Posted by kf...@collab.net.
Jani Averbach <ja...@jaa.iki.fi> writes:
> I think they are not. I don't know how I should replay db logs
> (however, the thing that I don't know, doesn't count very much), if
> there is a need to replay them, and I think that this replay procedure
> is not documented anywhere easy place to find (can I start the replay
> process from log_file-N or have I to have all of them starting number
> one at hand? How can I recover a repository starting from rev N, using
> log-files? etc...).
Well, if it's a matter of documentation, we can fix that... (either by
writing it, or by referring to the appropriate BDB doc pages).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2003-11-26 11:38-0600, kfogel@collab.net wrote:
Here we go!
>
> What are the circumstances where a regular backup schedule with
> 'svnadmin hotcopy' is insufficient and one would actually need these
> space-eating logs? Are such circumstances common enough to warrant
> turning on the space-eating by default?
I think they are not. I don't know how I should replay db logs
(however, the thing that I don't know, doesn't count very much), if
there is a need to replay them, and I think that this replay procedure
is not documented anywhere easy place to find (can I start the replay
process from log_file-N or have I to have all of them starting number
one at hand? How can I recover a repository starting from rev N, using
log-files? etc...).
Secondly, I feel that the risk to accidentally
rm `svnadmin list-dblogs repo` by mental disorder is higher than the
need and benefits of the logs.
I feel much more comfortable with incremental svnadmin dumps.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by mark benedetto king <mb...@lowlatency.com>.
On Wed, Nov 26, 2003 at 11:38:53AM -0600, 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.)
>
Some data:
Data-point 1: Oracle
Oracle has two modes of operations:
Archive Log Mode:
This is in most ways very simmilar to the 4.1 behaviour.
No Archive Log Mode:
This is in most ways very simmilar to new, optional behaviour.
For Oracle, this is the default.
The scenarios where Archive Log Mode is typically preferred are for
1.) hot-standby: a "slave" instance of Oracle reads the logs as soon as
they are written by the "master" instance.
2.) backup of very large databases: once a database gets Very Large, it
becomes unwieldy to make full backups of it as frequently as desired.
Instead, occasional full-backups are made, and the incremental archive
logs are backed up between full-backups.
The principal drawback to Archive Log Mode is that the administrator
must write some sort of job to remove the archive logs once they
have been mirrored/backed-up. I have seen multi-million-dollar
Oracle installations freeze completely when the partition their
archive logs are being written to fills because this job fails for
some reason. For example, the backup server has some sort of
problem deleting the files. Kaboom.
Even Oracle, which is not known for its ease of administration, chooses
the "more maintainable" mode of operation for its default over the "more
fault-tolerant" one.
Data-point 2: SQL Server
I am less familiar with SQL Server, but it is my impression that it
only supports the "ring buffer" transaction log model.
Data-point 3: Postgres
Postgres "Write Ahead Logs" are periodically auto-truncated. There
is not (last I checked) an option to use them for replication.
Data-point 4: MySQL
A quick google search leads me to the assumption that MySQL functions
nearly the same way that Oracle does. It is not clear to me which
mode is the default, but given MySQL's reputation for low administrative
overhead, I'd guess that it's "auto-delete".
What I'm getting at here is that many applications that use write-ahead
logging either
1.) don't support keeping the already-checkpointed logs around
or
2.) support it, but not as the default
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by kf...@collab.net.
"C. Michael Pilato" <cm...@collab.net> writes:
> The comparison with CVS is unfair. The chances of completely ruining
> an entire CVS repository to the point of uselessness are sooooo much
> smaller than those for ruining a Berkeley DB environment.
Oh-ho, look who's suddenly all concerned with "fairness"!
Ahem. I'm fine now.
You're right, it's an irrelevant comparison.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by "C. Michael Pilato" <cm...@collab.net>.
kfogel@collab.net writes:
> 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. CVS
> doesn't even support such a thing.
The comparison with CVS is unfair. The chances of completely ruining
an entire CVS repository to the point of uselessness are sooooo much
smaller than those for ruining a Berkeley DB environment.
An analogy: Anybody here use DoubleSpace back in the day -- where
you're entire collection of data was effectively archived into one
giant file. And anybody ever get a single bad disk sector that
rendered that giant file -- and hence all your "real" data --
inaccessible?
> What are the circumstances where a regular backup schedule with
> 'svnadmin hotcopy' is insufficient and one would actually need these
> space-eating logs? Are such circumstances common enough to warrant
> turning on the space-eating by default?
Using logfiles alone as a backup mechanism has its pros and cons. On
the "pro" side, you have incremental backup capabilities, with a
(default) granularity of every megabyte of logged data. The obvious
"con" is that reconstruction of a repository from only logfiles must
necessarily be done from the beginning of the thing's life -- and that
could be a whole lotta logfiles to traverse.
Staying focused on this particular tradeoff, the best backup method,
therefore, is to use a combination of periodic hotcopies + logfiles
created/modified since your last hotcopy. But it isn't so black and
white, because our scope isn't strictly limited to these forms of
backup. We also have incremental repository dumps + rev-prop-change
archival, for example, which also has its own set of pros and cons.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
SPAM[RBL] Re: To remove or not to remove logfiles? (issue #1615)
Posted by Mike Mason <mg...@thoughtworks.net>.
kfogel@collab.net wrote:
>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.)
>
>
Another thing to bear in mind is that for Subversion to gain acceptance
as a decent version control tool it kind of needs to "behave itself" out
of the box (in as much as that's possible). It might be a problem if
people heard stories about it eating disk space, although eating data is
obviously worse. Similarly with the deltification -- it would be best
all round if Subversion configured deltification automatically, somehow.
Having said that, actual performance and usability of source control is
rarely a deciding factor (in my experience) for source control
selection. It's much more to do with what someone picked 12 years ago
when Windows 3.1 was all the rage. *sigh*
Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Wed, 2003-11-26 at 15:05, Ben Collins-Sussman wrote:
>
>
>>As someone already said, you need to be an expert to understand how to
>>make use of infinite logs, and you need to be an expert to decide that
>>such a catastrophic recovery option is actually *worth* infinite disk
>>growth from read-only operations.
>>
>>
>
>Furthermore, if you're enough of an expert to make use of the logs,
>you're probably also enough of an expert to recover most of your data
>from a slightly-corrupted repository, although the procedure may be more
>painful.
>
>So, I'd say the comparison with CVS *is* apt, if you assume an expert is
>involved. And if no expert is involved, then the logs are useless.
>
>
O.K., I give in. --bdb-log-keep it is.
--
Brane Čibej <br...@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
Re: To remove or not to remove logfiles? (issue #1615)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2003-11-26 at 15:05, Ben Collins-Sussman wrote:
> As someone already said, you need to be an expert to understand how to
> make use of infinite logs, and you need to be an expert to decide that
> such a catastrophic recovery option is actually *worth* infinite disk
> growth from read-only operations.
Furthermore, if you're enough of an expert to make use of the logs,
you're probably also enough of an expert to recover most of your data
from a slightly-corrupted repository, although the procedure may be more
painful.
So, I'd say the comparison with CVS *is* apt, if you assume an expert is
involved. And if no expert is involved, then the logs are useless.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2003-11-26 at 14:00, Justin Erenkrantz wrote:
> I say toss 'em by default. MBK's data points convinced me.
I agree.
As someone already said, you need to be an expert to understand how to
make use of infinite logs, and you need to be an expert to decide that
such a catastrophic recovery option is actually *worth* infinite disk
growth from read-only operations.
So I say let the "experts" deal with infinite logs and all ramifications
thereof, not the other 99% of us.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by kf...@collab.net.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> And, I'd agree with Greg that deltification should occur by default,
> too. But, that ship seems to have sailed. -- justin
Huh? No, it is going to occur by default, we just settled on a
solution (though logfiles must be removed on a regular basis for
deltification to do much good, of course).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, November 26, 2003 12:54:14 -0600 kfogel@collab.net wrote:
> Now I'm really starting to waver, after seeing MBK's data points, and
> Greg's point about read-only operations & deltification. Especially
> about the read-only operations. I mean, sheesh.
...
> But maybe today is that day?
/me nods
I say toss 'em by default. MBK's data points convinced me. In our
instance at apache.org, we'd have to turn off the BDB logs because of the
sheer volume of read-only transactions we'd expect. (No way to clean the
logs if everyone is doing read-only operations.)
And, I'd agree with Greg that deltification should occur by default, too.
But, that ship seems to have sailed. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>(90% of the patch Brane is working on will be the same whichever
>default we choose,
>
Yup
>so this discussion can continue while he codes.)
>
>
It already is. :-)
--
Brane Čibej <br...@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
Re: To remove or not to remove logfiles? (issue #1615)
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> > 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.)
>
> Well, three people have already disagreed with me, but: I strongly feel
> that the default should be to throw them out. It's Just Not Okay to
> have a repository which, by default, grows on read-only operations and
> also gets no benefit from deltification.
Now I'm really starting to waver, after seeing MBK's data points, and
Greg's point about read-only operations & deltification. Especially
about the read-only operations. I mean, sheesh.
The most convincing reason to keep the logs, IMHO, is that Subversion
is still immature, and there there might be some repository-corrupting
bug latent somewhere in the fs code. I still assumed that someday
we'd switch to tossing logs as the default; the issue was more about
when do we feel secure enough to do that...
But maybe today is that day?
(90% of the patch Brane is working on will be the same whichever
default we choose, so this discussion can continue while he codes.)
-Karl, a.k.a. Mr. Which Way Is The Wind Blowing Today
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To remove or not to remove logfiles? (issue #1615)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2003-11-26 at 12:38, kfogel@collab.net wrote:
> 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.)
Well, three people have already disagreed with me, but: I strongly feel
that the default should be to throw them out. It's Just Not Okay to
have a repository which, by default, grows on read-only operations and
also gets no benefit from deltification.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
SPAM[RBL] Re: To remove or not to remove logfiles? (issue #1615)
Posted by Mike Mason <mg...@thoughtworks.net>.
kfogel@collab.net wrote:
>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. CVS
>doesn't even support such a thing. What are the circumstances where a
>regular backup schedule with 'svnadmin hotcopy' is insufficient and
>one would actually need these space-eating logs? Are such
>circumstances common enough to warrant turning on the space-eating by
>default?
>
>
I'd rather the logs were cleaned up by default -- anyone who cares about
integrity is going to read the book section on "backing up your
repository" and sort their backup procedures (this is the first section
I read after getting the repos working, and now I do a daily dump). If
that's not good enough, docs should (and I think already do) include
bits about ultra-paranoia style hot backups and the like. Maybe that
section is where switching log retention back on could be described.
Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org