(Illustration by Gaich Muramatsu)
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, JanReceived on 2003-06-02 10:29:46