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?

Jan