Hi Jan,

Thanks for your reply.  Coda is one of those topics that fills my head
with a storm of questions that I try to answer by reading and
experimenting until I collapse out of exhaustion.

> Hi,
> 
> Read-only replication is not used that much anymore. The reasons for
> read-only replication are still the same.
> 
>   Conflicting updates cannot be allowed to occur at the root volume
>   since this would make the entire Coda file system inaccessible.
>   However, if the root volume is not replicated, the availability of the
>   entire Coda file system depends upon the availability of the server
>   acting as the custodian for this one volume.
> 
> But instead of having difficult to maintain read-only replicas, it is
> simpler to have a regular read-write replicated volume and then use
> ACL's to protect it from updates by users who are not administrators,
> this ofcourse assumes that sysads know not to mess with the root volume
> during working hours ;)

What is meant by a read-only replica? I would have assumed that the
client would write to the read-write server and the read-only replicas
would copy from the read-write server.  Is this the correct
interpretation of read-only replica? (I fear not....)

What does the backup executable do exactly? Is it something similar to:

volutil lock Vol-ID
volutil backup Vol-ID
volutil clone volume-ID -n Vol-ID.backup

What is the smantics of "volutil backup"? "volutil clone"?

> The advantage of rw-replicated volumes are;
>  - Clients can cache the file objects in the volume, and perform rapid
>    cache validation when reconnecting. With non-replicated or read-only
>    volumes there seem to be some problems, their objects tend to be
>    ejected from the cache quite soon after disconnection, which reduces
>    the usefulness of disconnected operation.
>  - The replication strategies will make sure that all replicas are
>    consistent. So the administrator does not have to use the complicated
>    dump/restore sequence.
>  - ACLs protect the volume from possibly conflicting updates by regular
>    users.

AFAICT,  in strongly  connected mode,  writes are  done  by contacting
*each* server  in turn. This means  that the client has  to wait until
all servers have completed the write operation.

> A disadvantage is, that it is possible to get a very difficult to repair
> conflict in /coda (the root directory of the root volume). The only way
> to fix this is by creating a temporary root to mount and repair the
> original root volume. The `alert' sysadmin will normally make sure that
> all servers are up, that his client is strongly connected to all
> servers, and that he is the only person modifying the rootvolume at that
> time, to avoid such a conflict.

Regards, Ceki