Coda File System

Re: Multiple coda servers

From: Liu Wei <>
Date: Sun, 12 Sep 1999 09:47:52 +0800
Now, I can create a replicated volume on multiple servers, but can I
create a non-replicated volume which spans on multiple servers. ( ie.
each server contains the different subtree of the volume )


-----Original Message-----
发件人: Jan Harkes <>
日期: 1999年9月12日 7:15
主题: Multiple coda servers

>On Sat, Sep 11, 1999 at 01:54:56PM -0400, wrote:
>> I do have some other questions:
>> In AFS, every cell is under the /afs.  Does coda do the same thing?
>> If I install the server on a nother pc,  and build another volume,
>> will both show up under /coda?  or do I have to do something on the
>> SCM to make that happen?  Can I change which machine is SCM?  And if I
>> can, how?
>Coda currently has no support for importing other administrative cells
>into it's local namespace. (aka. mounting volumes from some other Coda
>installation into your own tree).
>However, it does support multiple servers within one administrative
>cell. And volumes can be replicated across several servers.
>To go from a single server Coda setup to a multiple server Coda setup is
>relatively painless if you follow the following steps. Maybe this is
>even documented in the Coda-HOWTO, if it isn't it probably needs to be
>- On the SCM, add to /vice/db/servers the name of the new server, with a
>  new unique server-id (in the range 1-126 or 128-254, the reason why is
>  one of the few things in the FAQ on the Web).
>e.g. /vice/db/servers
>    1 SCM
>    2 NewServer
>- Also on the SCM add new volume-server-groups to /vice/db/VSGDB.
>  This defines which servers are responsible for storing volume
>  replicas. A volume can at most be replicated across 8 servers, it is
>  theoretically possible to resize/shrink VSG's, but nobody has
>  succesfully done so.
>  The numbers are interpreted as hexadecimal, and seem to have once been
>  used as multicast IP-addresses, that's why they start with E0 == 224
>  == multicast ip. Multicast support is present in rpc2, but unlikely to
>  work.
>e.g. /vice/db/VSGDB
>    E0000100 SCM
>    E0000101 NewServer
>    E0000102 SCM NewServer
>- Install your second server, and at the question "Is this the master
>  server, aka the SCM machine? (y/n)", answer `n'. And finish the setup
>  by giving the hostname of the SCM, and configuring RVM.
>- Start the update client on the new server, on a redhat installation
>  this is done by:
>    /etc/rc.d/init.d/update.init start
>- Check whether the files in /vice/db are updated. Otherwise restart the
>  updatesrv on the SCM (/etc/rc.d/init.d/update.init stop; ... start).
>  When the prot_users.db etc. files have appeared, everything should
>  be ready to start the auth2 daemon and the codasrv on the new server.
>Creating volumes is still done on the SCM, but you should pass another
>VSG identifier to the createvol_rep script.
>    createvol_rep replicated E0000102 /vicepa
>    # creates a replicated volume on both SCM and NewServer, according
>    # to the VSGDB show earlier.
>If you want to move the SCM, put the hostname of the new SCM in
>/vice/db/scm, and after this file has propagated, stop updateclnt,
>updatesrv and the auth2 daemon on all machines. Then simply restart all
>updateclnt, updatesrv and the auth2 daemons. Maybe check if /vice/db/scm
>is correct before actually restarting them.
>The codasrv itself doesn't care whether it is an SCM or not, the other
>daemons have to know it because of the simple replication technique of
>copying the files in /vice/db from the SCM to the other servers.
Received on 1999-09-11 21:49:56