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
