On Tue, Oct 05, 1999 at 11:44:08AM +0200, Gulcu Ceki wrote:
> The third paragragh of that section reads: "If you already have a
> read-only replicated root volume but want to update it, you  should
> mount the read-write version of the root volume elsewhere  and make
> changes to this volume."
...
> Clearly, it is unwieldy to have the administrator intervene manually
> whenever "updates" are made to the root volume. That is illogical
> since it would mean that Coda is more cumbersome than tools like
> mirror and rdist.
> 
> I am surely missing something. Can you enlighten me?

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 ;)

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.

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.

Jan