(Illustration by Gaich Muramatsu)
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? JanReceived on 2007-05-17 11:11:12