(Illustration by Gaich Muramatsu)
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, CekiReceived on 1999-10-06 04:42:57