monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Time to create a monotone cluster?


From: Grahame Bowland
Subject: Re: [Monotone-devel] Time to create a monotone cluster?
Date: Sat, 31 Mar 2007 15:12:39 +0800

On 24/03/07, Richard Levitte - VMS Whacker <address@hidden> wrote:
In message <address@hidden> on Fri, 23 Mar 2007 13:42:46 +1100, Daniel Carosone 
<address@hidden> said:

dan> On Fri, Mar 23, 2007 at 03:28:59AM +0100, Richard Levitte - VMS Whacker 
wrote:
dan> > I believe I've just finished the framework for a simple
dan> > monotone cluster.  It's all in the following scripts:
dan>
dan> Cool. No time to look at it just right now, but I'm happy to host
dan> a node.

Thanks.

I just saw that someone thought the monotone database was getting
clustered last night.  There's currently no such effort underway, but
I'll confess to having thought of it.  Before that, though, I'll do
some tests on my own servers.

Hi guys

It'd be great to get angrygoats.net (which runs viewmtn, but does not
currently run a monotone server) in the cluster. At the moment I'm
doing a pull from venge.net every fifteen minutes, it'd be good to
improve that to something event-driven

I can easily enough start running a public monotone server, but
there's one catch - can anyone think of a solution?

I've got viewmtn running, and a number of long-lived mtn processes
reading from the database. I've recently modified viewmtn to notice
when the db file mtime changes and restart the mtn processes.

The trouble is updates; these lock the database, and the readers can't
access it. People start getting error pages when accessing the web
page. What I'm currently doing is:
 - copy the database file to a temporary file
 - pull into that file
 - do a atomic rename() to replace the old database file

This is quite transparent to any running mtn processes, as they just
keep using the old database until stopped. However, it's slow and more
than a little crude - and it will suck horribly when trying to deal
with regular updates.

I can't think of a better solution short of some sort of union
filesystem that allows me to have the temporrary db file be based upon
the original, removing the slowness of the copy. That could work, but
it's still pretty horrible for anyone else wanting to run a viewmtn
server..




reply via email to

[Prev in Thread] Current Thread [Next in Thread]