Jan Harkes wrote :
> On Tue, Apr 08, 2008 at 06:02:33PM +0200, Pierre LEBRECH wrote:
>   
>> So, I went into trouble with replicated volumes. I decided to reset
>> everything and start one new root volume on my 2 CODA servers. It helps
>> me to learn CODA a bit more.
>>
>> On the SCM, I removed /vice/db/VRList. Then, I ran this command :
>>
>> # createvol_rep rootvol server1 server2
>>
>> The file /vice/db/VRList has been updated with one fresh line. Seams OK
>> on the 2 servers.
>>
>> And I tried this :
>>
>> # volutil -h server1 getvolumelist
>>
>> and then : volutil -h server2 getvolumelist
>>
>> And I got 2 different lists! On one server (SCM) I was able to view very
>> very old volumes. Where does this list come from? Where is the volume ID
>> in this list?
>>     
>
> There are several places where volume information is stored/available.
> At the lowest level each server knows which volumes were created on it,
> this is what you get with 'volutil getvolumelist'.
>
> The only way to get rid of those volumes is to either destroy them with
> purgevol_rep (which relies on having the original VRlist file and such)
> or with 'volutil purge', or by really starting from scratch and wiping
> the recoverable memory (RVM log and data) on the server.
>   
Yes. I've found the volutil tool with the purge option. I used it on the
2 CODA servers. It worked well. The only thing on which I had problem
was on identifying the volume ID and the volume name from the list given
by the getvolumelist option. But now it is OK. I'm
just wondering why there is a letter before the volume ID (that I had to
ignore, ex : I1000002) and why there is a 'W' letter before the volume
name, and also why I had to use the small number after the volume name!
(test.1 instead of just test). C'est la vie!

Now the list given by getvolumelist is empty on the 2 CODA servers.

But my VRList file was not empty. So I removed the content of that file
with vi.
Then I ran this command : volutil -h localhost makevrdb /vice/db/VRList

Now, VRList and VRDB are both empty.
Then I typed : volutil -h localhost makevldb /vice/db/VRList


> The second layer is where we have the volume location database (VLDB),
> which is built by pulling the individual volume lists from all servers,
> combining them into a single /vice/vol/VolumeList file and then hashing
> that into a the binary lookup table that is stored as /vice/db/VLDB.
>   
The name I have is : /vice/vol/BigVolumeList
It is updated by bldvldb.sh
> The top layer is the more abstrace volume replication database (VRDB),
> this is built from the /vice/db/VRList file which is updated by the
> createvol_rep and purgevol_rep scripts. It describes which lower level
> volumes need to be considered as replicas of each other. How to group
> everything together.
>
> So you got rid of the higest level information which described which
> lower level replicas together form a replicated volume, but the actual
> volumes were not removed.
>
>   
>> How is it possible to definitly remove old volumes?
>>     
>
>   
So with the steps I've done above, everything seams to be clean. Now, I
ran this command :
createvol_rep rootvol server1 server2
result was OK.

Now, I want that my CODA clients be able to access this root volume.
Currently, on client side, /coda is empty.
The creation of my replicated volume rootvol does not change anything.

Question : how one can make a volume a real root volume from the client
side? How my clients be able to see my new root volume?

Hum. I think I have the answer. In fact, the name of the root volume
must be "/". So, I have just removed my volume named rootvol. Then, I
created of volume named "/". And a few seconds later, my clients were
able to see my realm under coda. Obviously, it is empty.

Now, I have populated my realm with the content of a directory saved
earlier. Everything went OK.

Oh one more question : when I removed my rootvol volume (with volutil
purge), the VRList was not updated. I had to manually remove it from
VRList and make the /vice/vol/BigVolumeList updated manually as well. Why?

Well, now everything seams to be OK. Ah, a good thing!
> Easiest at this point (since you want to remove _everything_) is to
> reinitialize the server's RVM by running, "vice-setup-rvm".
>
> Jan
>
>
>