On Fri, Nov 29, 2002 at 10:04:39AM -0500, Stephen J. Turnbull wrote:
> a professional with an ambulance on call", I managed to trash my V*DBs
> _and_ the text files (volutil really ought to make backups...).

Trashing the V*DB's shouldn't be a problem as long as those can be
rebuild from the textfiles. And as far as these are concerned, the
BigVolumeList is basically a concatenation of the internal list of
volume we get from the servers with 'volutil getvolumelist' (this
is not a dump the VLDB, but obtained by iterating through the volumes
on the server).

So only /vice/db/VRList is hard to reconstruct.

Glad you managed to get everything back up though.

> Weirdness: "volutil lookup coda:root.0 /tmp/info" puts the expected
> info in the file, "volutil lookup 100001 /tmp/info" does not, although
> both name and hex ID work for all the other volumes I've tried.

maybe 'volutil lookup 0x100001 /tmp/info' works? Actually I believe that
the server indexes it's volume by the decimal volume-id instead of the
hexadecimal representation, so 'volutil lookup 1048577 /tmp/info' should
work in any case.

> Question: /vice/srv/SrvLog has the following in it.  Is this a
> problem?  What can I do to clean out the logs?  I should note that
> this is one of the two volumes that causes the most conflicts for me.

I've seen that on our production servers as well. Some of these 'errors'
should be fixed up by the salvager, but I believe that the unreachable
entries are not garbage collected out of fear that the salvager might be
wrong and we would cause problems for server-server resolution.

Jan