On Wed, May 28, 2003 at 12:28:31PM +0800, Jeremy Kuo wrote:
>     2. Use "volutil clone" to take a clone volume named coda.volrep1.clone1 for coda.volrep1.

Hmm, that shouldn't be possible. The 'logical' replicated volume
coda.volrep1 should have 2 underlying replicas on the servers named
coda.volrep1.0 and coda.volrep1.1. You should not be able to clone the
replicated volume as it doesn't exist on the servers.

>        Run "bldvldb.sh".
>        ==> use "volutil getvolumelist" can see the read-only coda.volrep1.clone1 created.
>     3. cfs mkmount /coda/volrep1/clone1 coda.volrep1.clone1
>        ==> a dangling link appeared

Venus doesn't use the equivalent of volutil getvolumelist. Venus
actually uses a special GetVolumeInfo rpc2 call which is looked up in
the VRDB and VLDB files. In this case the information should be in the
VLDB file is constructed by bldvldb.sh which actually got the required
information from the output of volutil getvolumelist.

So in a way, if the volutil command has the right information the VLDB
should have the correct data and the remaining problem is that the new
data hasn't been re-read by the servers. That is typically an indication
that the updateclnt and/or updatesrv daemons on the servers are not
running. The update client daemon check the server for a new version of
the file fetches it (check timestamps on both servers) and signals the
server to re-read the VRDB and VLDB files (check SrvLog which should say
'New Databases have arrived' or something similar)

Jan