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
added/removed/updated.

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 ;)

Jan


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
		  anything.

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
		  snapshot.

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
		  operation.
    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.