On Mon, Jun 25, 2007 at 01:16:57PM +0100, Ziggi wrote:
> 5. VRList changed to the following
> 
> dir 7f000002 1 02000003 03000001 0 0 0 0 0 0
	       ^
	That should be 2, to indicate there are 2 replicas.

> 6.
> root_at_server1:/vice/db# bldvldb.sh server1
> Fetching volume lists from servers:
> V_BindToServer: binding to host server2
> GetVolumeList finished successfully
> server2 - success
> V_BindToServer: binding to host server1
> VLDB completed.
> root_at_server1:/vice/db#

You also need to rebuild the VRDB, (volume replication data base)

    volutil makevrdb /vice/db/VRList

> 9. Started venus and connected both client to server1.
> 
> 10. cfs flushobject dir
> 
> root_at_server1:/coda/server1# cfs flushobject /coda/server1/web/
>        DANGER:   these files will be lost, if disconnected
>        Do you really want to do this? [n] y
>        Fools rush in where angels fear to tread ........
> Can't flush active file
> root_at_server1:/coda/server1#
> 
> Note: On both servers VRList are the same.
> 
> I tried cfs  flushobject several times and still no success.

What are you trying to achieve with flushobject here? Reinitializing
(and in some cases restarting) the client) should be enough to force it
to requery the volume information. You can check with "cfs whereis
/coda/server1/web" if the clients knows that the volume is replicated.

Really, for people who are just getting started, I really recommend not
trying to dynamically grow or shrink volumes. There is a lot that can
and will go wrong, I recently fixed a bug which would result in a server
crash on the first mutating operation when the resolution logs are
re-enabled after a server restart.

Also, we don't yet have a way to inform clients about the fact that a
volume's replication has changed so client that are not reinitialized
will only see part of the group and their writes will not keep all
available replicas consistent. Another client that can see all replicas
would be detecting the differences and triggering resolution, but if
there is no other client there is a good chance that the resolution logs
fill up.

> One last Question:
> when replication works - can each client be connected to different servers?

That is not how replication works. Clients connect to a realm, which is
really more like a cloud of servers. A subset of servers within the
cloud is designated as 'rootservers', we send all volume location
requests to this subset.

So how does the client identify the subset, the simplest way is to use a
specific server name, then that server will be used for all volume
location requests (even if that server does not host a replica of the
volume). The problem is that if that one server goes down none of the
clients can discover where any volumes within the realm are located,
even if all other servers are still reachable.

So a better solution is to provide a mapping from a realm name to a
group of servers. This can be done either by adding a SRV record to dns,
or by adding a line in /etc/coda/realms which contains the realm name
followed by the list of the root servers for that realm.

Jan