Hi Jan,

On Sat, 12 Mar 2005 00:03:02 -0500, Jan Harkes <jaharkes_at_cs.cmu.edu> wrote:
> On Fri, Mar 11, 2005 at 06:26:40PM -0300, Gabriel B. wrote:
> > I decided to start over. I wiped all coda and venus conf
> >
> > vice-setup was praticaly this:
> > /vice
> > yes, scm
> > scm id 1
> > user codaroot with uid 1075
> > /vice/LOG 20M
> > /vice/DATA 90M
> >
> > then vice-setip-srvdir
> > use /vicepa
> > 2M files
> 
> I thought vice-setup already ran vice-setup-srvdir, why run it
> separately? And if vice-setup didn't complete normally your server might
> not be running. At the end of vice-setup it (should) ask if it can start
> the various daemons, it should start
> 
>     rpc2portmap updatesrv updateclnt auth2 codasrv
> 
> And once codasrv is started it asks if it can create the rootvolume.

I'm using the .deb package from CM servers. It never asked me about
root volume. I even opened a thread asking if the docs were outdate
because of this.
 
> > pbtool
> > > nu bossnes
> > > ng www 1076 (bossnes id)
> >
> > createvol_rep / camboinha.servers/vicepa -3
> > that didn't worked. i waite 2hours and ctrl_Clled.
> 
> Where did you get that '-3'?

from the list command
GROUP www OWNED BY bossnes
  *  id: -3
  *  owner id: 1076
  *  belongs to no groups
  *  cps: [ -3 ]
  *  has members: [ 1076 ]
 
> > volutil create_rep /vicepa / 00001
> > bldvldb.sh
> > (a valid workaround?)
> 
> No it is not, since this only creates the underlying volume replica
> (which should be named "/.0") And again, where does that strange 00001
> number come from? The createvol_rep script does this first but then
> creates the replicated volume by dumping the existing (currently empty)
> VRDB into the /vice/db/VRList file, appending a entry that describes
> which replicas are part of the replicated volume and recreates a new
> VRDB file from the data in the updated /vice/db/VRList.

hum... is it in binary form or human readable? can you send an example?

> 
> > now to the client.
> 
> While the server is not correctly set up... You only have an underlying
> volume replica so if your client mounts it there are no version vectors
> and it will not keep anything cached locally when disconnecting because
> there is no way to revalidate the cached objects.
> 
> > now, lets make some mount points for the future volumes:
> > bossnes# mkdir /coda/camboinha.servers/htdocs
> >
> > and that's it. it will hang in there pratically forever. until i ctrl+c it.
> 
> Actually venus internally is probably still hanging at this point, you
> just told the kernel to stop waiting for the result. But indefinite
> hanging is quite unusual. Timeouts are set to about 60 seconds before an
> RPC operation aborts, except when the server responds with a BUSY.
> 
> The only 'worst case' that I know of is when we initially contact a
> realm since we are hit by multiple RPC2 timeouts, one when we try to get
> the rootvolume name, one when we fall back on getvolumeinfo, at this
> point the mount fails, but with a colorizing ls we get an additional
> readlink and getattr on the mountpoint both of which also trigger an
> attempt to mount the realm (i.e. another 4 timeouts). So we end up
> blocking for about 6 minutes if the realm is unreachable.

I just let a "cfs lv /coda/camboinha.servers" running friday. It's
monday and i had to control+c it.
The server is still running tought.

now, i did a cunlog and a clog, and "time ls -la /coda/"
<ctrl+c>

real    14m44.403s
user    0m0.001s
sys     0m0.003s

> > then. i restart both server and client, and sometimes it shows the
> > server inside /coda. others time it simply shows an empty /coda
> >
> > i then created two more volumes. now venus report  "2 volume replicas"
> 
> Did you mount those volumes then? How would venus know about the newly
> created volumes? Those 2 replicas are probably the one that is at /coda
> and the one at /coda/camboinha.servers.

It's show in the venus startup. And i'm starting it with -init every
time. cfs hangs as well, so i will never know wich volumes it claim to
have found.

> > the logs have nothing even with the highest debuglevel.
> 
> Venus is really verbose at the highest debuglevel, so verbose actually
> that I tend to limit myself to 100, and normally only set it to that
> level for a short period of time around the operation that I'm trying to
> figure out.
> 
> > cfs lv /coda/camboinha.servers and it magicaly appears there
> > ...with the file the creating i ctrl+Celed before when it hang. so, it
> > probably is the cache. the weird part is that i delete all rvm files
> > on the client, and every time i start it up with -init. anyhow, as
> > soon as i create anything it hangs.
> 
> It probably did end up creating the file on the server because ^C only
> makes the kernel module stop waiting for the result. Those hangs are not
> normal, and especially not seeing anything traffic on port 2432, there
> is probably something wrong with ip-addresses, such as your server
> claiming it's ip-address is 127.0.0.1 or some other address that is
> unreachable for the client.

I think i will start over again with the tgz version. 

Did someone have success using the .deb version? I tried it with 3
sets of server/clients. each more troublesome than the other.

Thanks,
Gabriel