On Mon, Jun 02, 2003 at 03:30:51PM +0200, Ivan Popov wrote:
> If there is anybody feeling that an arbitrary (or otherwise not "/") root
> volume name is a must - please step forward and argue!

Ok, let's say I'd like to provide a public root to machines that are
connecting from outside of CMU and a private root for internal machines.

An alternative setup for this situation would be to use 2 realms, where
coda.cs.cmu.edu is the public realm and coda-internal.cs.cmu.edu is the
internal realm, but then I have to keep the user administration between
the two realms synchronized and users have to authenticate to both
realms. An advantage of the 2 realm setup is that the paths remain
identical independent on location.

Another reason is that the actual rootvolume might have a (temporary)
problem that makes it inaccessible. If this happens at a bad time the
administrator could create an alternative root which allows users to
access their data while the problems in the original volume are
resolved.

Any arguments about avoiding the cost of this RPC can be ignored as this
RPC2 call is only used the first time we connect to a realm. It would be
far more valuable to figure out why version vectors are not what a
client expects after weak reintegration and we refetch files that were
just written. Or why volume version vector validation often seems to
fail even when we know there have been no changes in a volume.

In a way clients 'ping' a server the first time they connect to a realm,
this gives an initial and reasonably accurate feedback about expected
network latency for rpc2,i the server processing time for this call
should be near zero and constant. Also because this call is guaranteed
to return something and even works on a problematic server it provides
debugging functionality. If getrootvolume fails, we must have a network
or routing problem. If it succeeds we are most likely looking at a
VRDB/VLDB issue.

Just playing devil's advocate here,

Jan