On Sat, May 19, 2007 at 12:12:56AM +0200, Enrico Weigelt wrote:
> is it possible to let Coda do an partial or on-demand mirroring 
> (instead of an complete mirror) ?
> 
> Example situation:
> 
> * An HQ, where the server and some mobile clients live. 
> * An outpost with an local server, als some mobile clients.
> * HQ + Outpost are linked to the net w/ DSL (ugly latency!)
>   and connected via VPN.
> 
> The primary filserv is in  HQ, ut the output server should
> function as cache for the clients.
> 
> It such an setup possible ?

At some point we experimented with a model where the 'outpost' would
have a read-only clone of a Coda volume, for instance last nights
backups. Then if a client requested a file that hadn't been changed it
would be fetched from the 'staging server'. Normal write traffic as well
as requests for recently updated files would still be passed to the real
servers.

This was mostly a proof of concept, and although it does save bandwidth
it introduces some management problems as the staging server has to be
able to intercept all traffic, so it had to either have access to the
shared server secret or use unencrypted connections.

If I were to implement a similar scheme now it would most likely be
based on the lookaside caching mechanism, possibly using convergent
encryption. Where a local caching server would store encrypted copies of
files, but the attributes would still be fetched directly from the
remote servers. Or even avoid the caching server and have Coda clients
broadcast/listen for data requests and share their caches.

Splitting a replicated volume across 2 poorly connected sites is not as
efficient, clients would still have to talk to the remote site to detect
possible inconsistencies and the resolution protocol involves about 5 or
6 server-server exchanges to lock the volume at all sites, gather
information about the conflict, push out the final solution and compare
whether every replica has reached consensus.

Jan