root-vol is really 'ftw' -  but seeing how it maps to the replicaid
shows that yeah, it was mounting ftwo instead.  OK, thanks.

It sounds like those return values will map nicely to useful messages,
good.  Thanks again for the help.

Randy

----- Original Message -----
From: "Jan Harkes" <jaharkes_at_cs.cmu.edu>
To: "Randy Harmon" <rjh_at_fortheweb.com>
Cc: <codalist_at_coda.cs.cmu.edu>
Sent: Tuesday, October 09, 2001 1:37 PM
Subject: Re: volutil getvolumelist doesn't match VRList


> 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
>