Coda File System

Re: volutil getvolumelist doesn't match VRList

From: Randy Harmon <>
Date: Tue, 9 Oct 2001 14:03:18 -0700
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.


----- Original Message -----
From: "Jan Harkes" <>
To: "Randy Harmon" <>
Cc: <>
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
> > > server even report attaching the ftw.0 and test1.0 volumes
> > > startup?
> >
> > Right, I'm not getting any logging from the server until I tell it
> > shutdown, which I didn't figure was related.
> It shouldn't be, 5.3.15 is missing an fsync after writing anything
> the log. So the messages are stuck in the stdio buffers. Either
force a
> logswap (volutil swaplog), or shut down the server and everything
> 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 -
> > 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
> 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
> > > and when the server was restarted it simply started back from
> > > 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
> > the same RVM stuff as the server before realizing that I needed to
> > Venus be file-based for its RVM.  CAUTION, says venus.conf - don't
> > that.  Ahem.
> Ok, so starting your client 'wiped' the server and the whole VRList
> basically useless because it describes a server state that doesn't
> anymore.
> > I'm still curious about RPC return codes #22 and 103 - I'd love to
> > 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
> turn up an entry in the VRDB (list of replicated volumes) or VLDB
> of volume replicas). Once the volume is found the server that hosts
> volume according to the VLDB is queried for information and it
> with 103 (VNOVOL) when it doesn't know about the volume.
> > I've blown away all the data to restart the configuration, and
> > had much better success.  Only trouble I'm seeing now is this
> > 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
> in.
> Jan
Received on 2001-10-09 17:04:00