On Mon, 4 Feb 2002, Greg Stein wrote:
> On Mon, Feb 04, 2002 at 12:02:44PM -0500, Daniel Berlin wrote:
> > Of course, I really meant this patch, instead, which uses the apr_thread
> > functions. :)
>
> I don't believe the server should be doing this, and for a couple reasons:
>
> 1) threads are not always available
....
> 2) there is potentially more work than this since Apache can open the FS
> multiple times (from different processes); we'd want to ensure there is
> only one "log killer" running for any repository
> 3) Apache opens/closes the FS on each request;
Really?
Eek.
> this thread would barely get
> started before it died; even worse, it would introduce context switching
> on every request, when we opened the repos
This could be fixed easily, by having the log file archiver open the db
itself anyway when the module starts.
etc.
> 4) people might want to *keep* those logs; they can be used to replay the
> database back to a fixed point, or they can be shipped off to another
> machine to replicate the database (thanks to Kirby for these ideas)
Except, it's really not as feasible as it sounds to keep the logs on the
same machine, due to disk space issues (they really just add up too
quickly).
Replication is your answer here, and it doesn't require keeping the log
files on your main machine.
Why?
Because you can set up a replicated client that is a log file only client,
specifically for this purpose.
People who need to keep log files in case a disk blows up are *much* more
likely to do this, and simply have this machine archive the log files
somewhere, than to risk running out of disk space on an important server
that may be doing other tasks.
In fact, specifically, this is one of the reasons replication was added
to Berkeley DB.
The only reason to keep absolutely every log file is if you can't lose a
second worth of work after your disk blows up completely.
And, BTW, it also assumes you aren't in some kind of redundant array where
a disk blowing up is just fine, which, if you can't afford a seconds worth
of loss, you probably already have.
Keeping every log file by default is solving a problem that is already
solved in multiple ways.
It's something users are going to complain about.
Especially since users include more than just people who want to use the
server portion. Their will be plenty of people who use it for local
repositories who will be completely turned off by this behavior.
> I'm perfectly happy to put a log-killer.sh script into /trunk/tools that
> people can run (feed it a list of repositories to keep clean).
> Administrators can use that script if they choose.
As you wish.
I still think it's the wrong answer for the majority of people.
Its one thing to have it configurable, defaulting to not keeping them or
keeping them for some time interval. But requiring a separate script just
adds another step most people have to take to set up subversion.
>
> Cheers,
> -g
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:04 2006