Coda File System

Re: general newbie-question about data replication

From: Jan Harkes <>
Date: Wed, 18 Jul 2001 08:11:31 -0400
On Wed, Jul 18, 2001 at 08:30:47AM +0200, Michael Radzewitz wrote:
>                                              The coda-server is able to do
> this but it needs one SCM to control all actions. Is there a way of setup
> more than one SCM so that the second or third one will take over the control
> if the first one fails? 

Ok, big misunderstanding here. Yes, we do have a SCM (System Control
Machine). However, it does _not_ control all actions. The only way the
SCM is different is because the user and volume databases are using a
very simplistic replication mechanism. They are only written to on the
SCM and then copied over to all other servers. As a result, the SCM is
only needed during volume creation and destruction, and when users are

During regular day-to-day operation the SCM is just another server. Any
server can provide a client with volume location information, all
servers independently service requests for the volume replicas that are
stored on them.

All servers have the same information available as the SCM and
essentially have the same capabilities. If the SCM is missing, new
volumes cannot be created, and in case the SCM is truely dead the only
thing that has to be changed is to tell all clients who will become the
new SCM. That way they know who to query for updated databases.

    # echo new_scm_server_name >> /vice/db/scm
    # /etc/rc.d/init.d/update.init restart

Now on to the rest.

> i am looking for a filesystem which is able to synchronize some files among
> some different servers. I think but i am not sure if the coda-file-system
> will do this in my situation.

This should probably become an entry in the FAQ, preferably annotated
with links and people's experiences with the various methods. Right now
it is most likely a bit biased, because I'm writing this down ;)


Ways of having the same files accessible on multiple machines,

one way mirroring,
    rsync 	- Only syncs at intervals (when using the cron).
    omirr	- Kernel patch + daemon that updates the slave.
    CVSup	- Works well with CVS archives but can handle

true-sync tools
    Unison	- Heuristically derives a log of changes from
		  observing the differences between 2 clients. Then
		  exchanges these logs, no server involved.

central repository
    CVS 	- Have to explicitly check-in/out updates. Keeps a full
		  history, so it is possibly to roll-back to an earlier

network filesystem
    NFS, Samba	- Without the server, all access is lost.

distributed filesystem
    AFS		- Read-only replication.
    Coda distributed file system
		- 'Write many, read one' replication and disconnected
    Intermezzo	- Keeps a log of changes at kernel level, ships logs to
		  the server and receives update logs. Also handles
		  disconnected operation.
    Rumor replicated file system
		- Optimistic peer-to-peer replication, no server involved.
Received on 2001-07-18 08:11:36