Coda File System

Re: Coda deployment

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Thu, 12 Jun 2003 11:09:25 -0400
On Thu, Jun 12, 2003 at 01:22:03PM +0200, Dick Kniep wrote:
> So, to avoid these kind of problems, could I disconnect the servers and
> regularly reconnect them to allow for the replication? (every hour or
> so) or do I get into another mess? Result will off course be that I will
> have some conflicts if people start working on a document on both sides,
> but I think that is a lesser evil, and it will only occur seldom.

You'll be fixing up conflicts the rest of your life and hate me :(

Best setup is to have 'independent' servers in each location. They can
be in the same realm, but shouldn't share volumes, except the root
volume that is modified as little as possible (by administrator only).

This way most people will have their files on their 'local' server but
can still access files at the other location which are stored on the
remote server.

i.e.

    /coda/myrealm/home/kniep  -> #A:h.kniep
    /coda/myrealm/home/sjoerd -> #B:h.sjoerd

As far as users are concerned they don't even see the difference between
files that are local or remote. Accessing a remote file will be a bit
slower initially, but because Coda client agressively cache files, it
won't hurt on further accesses until the file is updated. This will be
faster and probably more reliable for the users as well.

Another way is to split things up in different realms. This way the
location becomes an issue for the user, but it will avoid some
unnecessary traffic between the two locations.

Other solutions you could look at (which don't use Coda) are mostly
based around having all data at both locations and a cron job that runs
once ever 15 minutes or half hour and synchronizes any new files,
deletions or updates to the remote location.

 - unison, 2-way synchronization
 - rsync,  1-way synchronization, but by knowing what the 'master site'
   of a file or directory is you can push updates in both directions by
   running it twice.

Jan
Received on 2003-06-12 11:11:20