On Wed, Oct 06, 1999 at 10:41:19AM +0200, Gulcu Ceki wrote:
> > 
> > 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....)

No the only active replication in Coda is when all volumes are
read-write. In the case of read-only replicas, they are replicated by
the administrator who has to dump a rw replica, and then restore it as a
ro replica on the different servers.

> 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

Very close :)

volutil lock volid		# lock the volume
volutil backup volid		# clone the volume contents to a backup volume
volutil dump (-i) volid.backup	# (incremental) dump of the backup volume
volutil ancient ???		# mark the backup successful (used for
				  incremental backups)

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

They are very similar, except that backup can update an an existing
backup volume if it already exists. Clone can only create new volumes.

> 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.

Not really, or there is something wrong in the implementation of the
MultiRPCs. The data is sent to the three servers at the same time. There
is n times the traffic when talking to an n-replicated volume, because
we don't use multicast. It works a bit like:

    client sends ViceStore RPC to server1
    client sends ViceStore RPC to server2
		server1 receives ViceStore and sends SFTP Start
		server2 receives ViceStore and sends SFTP Start
    client sends server1 a window of data
    client sends server2 a window of data
		server1 receives data and sends SFTP ack
		server2 receives data and sends SFTP ack
    client sends server1 a window of data
		server1 receives data and sends SFTP ack
    ...
    client sends server1 last window of data
		server1 received all data and sends RPC reply
    client sends server2 last window of data
		server2 received all data and sends RPC reply

Ofcourse in real life, things never go this smooth. There are missed
acks, dropped packets, retransmissions, slow servers, etc.

Jan