On Thu, May 17, 2007 at 02:45:39PM +0100, prashant wrote:
> SCENARIO 1.
> 
> I have node1 configured as CODA server, node2 configured as its client, and
> node3 configured as CODA server, node4 configured as its client.

This scenario doesn't make much sense. A Coda client doesn't get
configured to bind to any specific server. All clients access data based
on logical volumes, you can have volumes that are located on only a
single server, and volumes that are replicated across several servers.

You can only write to files stored in Coda by using a Coda client, so
there is really no direct access to the stored data on node1 and node3
(the Coda servers) unless you also install clients on them. Coda's
replication strategy is to write updates to all available servers, a
client will also read attributes from all available servers, but read
data only from one of the available servers, typically the one who over
time has shown the best response times, since that one is most likely
less loaded or located closer compared to the other replicas.

> Questions:
> 
> 1. Which nodes actually does replication from the other?
> Is it the client that or the server that manages the replication of the 
> volume?

The server does not manage replication, but it does get involved
whenever a client detects that the servers are out of sync.

If all servers are reachable and because writes are sent to all servers
the replicas will remain in sync. If a server was unavailable during the
write there is an inconsistency between replicas. Any client that tries
to obtain the updated object will fetch attributes from all servers, so
if the server that missed the write has become available again it will
detect the inconsistency and inform the servers to resolve the
differences between the replicas.

> 2. If replication occurs, can it be rw on both sides?

Of course, the network could be split, so that each client only sees one
half of the replicated volume. They can both read and write, but clearly
the replicas will diverge. Then when the network connectivity is
restored and either of the clients notices an inconsistency between the
replicas it will inform the servers to resolve the inconsist object.

> 3. Is there any AUTOMATIC file version conflict resolution/ restore when 
> replication is going between the nodes.

Some inconsistencies are automatically resolved, others are left up to
an application specific resolution mechanism or the user. The ones that
can be resolved automatically are when one server has clearly missed an
update because it's version vector is strictly lower compared to all
others. In this case the updated version will be copied from any other
replica that has a higher version vector. Another trivial case is when
both servers actually received the same update, but the second phase of
the optimistic replication hasn't occured yet so the version vectors are
still out of sync. This is recognized because all operations are tagged
with a unique operation identifier. In this case we know the data is
identical (same operation was applied to all replicas) and the version
vectors are brought back in sync.

For directories there are some additional mechanisms.

> Many thanks for your answers

No problem, so when is your exam due?

Jan