(Illustration by Gaich Muramatsu)
On Wed, Mar 29, 2000 at 11:01:36AM +0100, fsg.student4_at_bt.com wrote: > Now I tested it with even another server (sf21). > Again the same: Both replicas are on the second server, but > none on the SCM. :-( > > The createvol_rep shows the following: > (Now sf2 being the SCM and sf21 being the replica.) > ================================================================= > [root_at_sf2 db]# createvol_rep coda:test E0000100 /vicepa > Servers are (sf2 sf21 ) > HexGroupId is 7F000000 > creating volume coda:test.0 on sf2 > V_BindToServer: binding to host sf2.ss.visual.bt.co.uk > Volume 15000001 (coda:test.0) created ^^^^^^^^ > creating volume coda:test.1 on sf21 > V_BindToServer: binding to host sf21.ss.visual.bt.co.uk > Volume 15000001 (coda:test.1) created ^^^^^^^^ This is very suspicious, the first part of the volume identifier on different server should be different. > [root_at_sf2 db]# more servers > sf2 2 > sf21 21 That looks ok.. but, the volume was created on different server. Hmm, sf2 picked the wrong server-id, it should have created '2000001'. > Fetching /vice/vol/Volumelist from sf21 sf2 > sf21 > V_BindToServer: binding to host sf2 > VLDB completed. > <echo coda:test 7F000000 2 15000001 15000001 0 0 0 0 0 0 E0000100 >> > /vice/vol/VRList> > V_BindToServer: binding to host sf2 > VRDB completed. Ok, this code seems to do a lookup of the server from the initial part of the volume identifier and binds to.... completely the wrong one. I guess there is some bad fuzzy matching of hostnames/volume-id's somewhere. > [root_at_sf2 vol]# more AllVolumes > # [Last line of unsorted volume list] > coda:test.0 15000001 sf21.ss.visual.bt.co.uk /vicepa 2 0 0 W 954320188 > 954320188 0 > coda:test.1 15000001 sf21.ss.visual.bt.co.uk /vicepa 2 0 0 W 954324236 > 954324236 0 And this doesn't look right at all either. There is a big mixup of servers here, I don't know what is causing it. What is listed in the various files in /vice/vol/remote on the SCM? JanReceived on 2000-03-29 11:36:22