(Illustration by Gaich Muramatsu)
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) JanReceived on 2003-05-28 00:51:01