On Tue, Oct 09, 2001 at 01:21:38PM -0700, Randy Harmon wrote:
> > volume with volume-id's that should already have existed. Does the
> > server even report attaching the ftw.0 and test1.0 volumes during
> > startup?
> 
> Right, I'm not getting any logging from the server until I tell it to
> shutdown, which I didn't figure was related.

It shouldn't be, 5.3.15 is missing an fsync after writing anything to
the log. So the messages are stuck in the stdio buffers. Either force a
logswap (volutil swaplog), or shut down the server and everything should
pop up.

> > > Uh... where's my root-vol?  Is what I'm wondering.
> 
> So, the client was able to mount /coda, but I'm not sure why - maybe
> it just grabbed the only volume it knew of.

Ok, rootvolume name is root-vol, this is looked up in the VRDB (i.e.
post-processed VRList) and gives replicated volumeid 7f000000, and
replica id 1000001. Then the replicaid 1000001 is looked up which id
found, although that is actually a volume ftwo.0 which itself believes
it is part of the replicated volume ftwo (volid 7f000002).

So this will cause some serious failures at some point.

> > It looks like the whole creation of the volume was 'forgotten about'
> > and when the server was restarted it simply started back from ground
> > zero. Now this kind of information is stored in RVM, which has a
> pretty
> 
> Uh, stored in RVM, you say.  right.  Well, I <blush> told Venus to use
> the same RVM stuff as the server before realizing that I needed to let
> Venus be file-based for its RVM.  CAUTION, says venus.conf - don't do
> that.  Ahem.

Ok, so starting your client 'wiped' the server and the whole VRList is
basically useless because it describes a server state that doesn't exist
anymore.

> I'm still curious about RPC return codes #22 and 103 - I'd love to see
> volutil and et cetera report more clearly what's going on in these
> cases, if reasonable.

Returncode 22 is EINVAL, returned in some places when the lookup doesn't
turn up an entry in the VRDB (list of replicated volumes) or VLDB (list
of volume replicas). Once the volume is found the server that hosts the
volume according to the VLDB is queried for information and it responds
with 103 (VNOVOL) when it doesn't know about the volume.

> I've blown away all the data to restart the configuration, and I've
> had much better success.  Only trouble I'm seeing now is this report
> when we first create the root volume:
> 
>     VolSetLogParms failed with Unknown RPC2 return code 103

We try to turn off resolution logging for singly replicated volumes,
however it passes the wrong info. I already got a fix for that checked
in.

Jan