> Nope I don't think that is it:
> 
> [bwoodard_at_trill vtools]$ cfs checkservers
> Contacting servers .....
> All servers up
> [bwoodard_at_trill vtools]$ cfs sa /coda System:AnyUser  rl
> /coda: Connection timed out

The volume must be in `Emulating' state, which happens in the following cases:
  - the server is down
  - the volume is waiting to be repaired (inconsitent)
  - the volume is waiting for user tokens before reintegrating
  - the volume is reintegrating

By the way, is /coda your only volume?

Reintegration (and probably repair) will only work when you are authenticated 
to coda. The command `ctokens' should show whether you have any coda-tokens.
If not it is possible to obtain tokens with `clog'.

$ clog
Password: <your coda password>
$ cfs checkservers
Contacting servers .....
All servers up

If the different coda-logging channels don't give any indication that 
reintegration is being done, there will probably be messages about 
inconsistent objects.

> I don't know if it will help but here is how I got myself into this
> state: I was at home moving my home dir from my laptop to the vice
> server. I have a 128Kb ISDN at home so coda occationally thought it
> had strong connection but most of the time it thought it had a weak
> connection. So anyway I was moving over my mail dir 28Mb literally
> thousands of files and I let the cpio -p go a bit too long before I
> paused it to let /coda reintegrate. Well venus crashed with that error
> listed above (I have learned that means that it runs out of CML
> entries). When I restarted it, it had that inconsistancy. I couldn't
> fix it and so I moved my mail dir to another spot and tried
> again. That is when I ran out of CML entries really quickly. The thing
> is it doesn't seem to want to reintegrate at all if there is any
> conflict. When I restarted, I still had the full CML entries from the
> dir that doesn't have any conflicts and I have the dir that needs
> repairing.

I know that running out of CML entries makes the client state extremely 
inconsistent. I can easily reproduce this, it happens almost always when the 
system runs out of cmlentries.

So we can try to salvage whatever is possible, with a high chance of `after 
effects', or reinitialize venus.

If you really want to work with the repair program to fix this let me know, 
for now I assume reinitializing is easier.

When you reinitialize venus, it is possible to redefine the number of 
cachefiles and cmlentries. I would suggest

cache_size_in_blocks/32 = #cachefiles
cache_size_in_blocks/8  = #cmlentries

so when you reinitialize with 40000 cacheblocks:
   venus -init -cf 1250 -cmles 5000

These settings are stored in persistent storage, so they will be used whenever
venus is started (and reset when venus is reinitialized). With these settings 
you should run out of cachespace, before you run out of cmlentries. And coda 
will return ENOSPC instead of trashing the system.

> A new documentation item that I discovered is that "cfs checkpointml"
> doesn't state that you need to put a dirname after it in either the
> manual or the man page. It took me a long time to figure out that you
> had to do something like "cfs checkpointml /coda" 

When you do not give a directory name, it will try to checkpoint your current 
directory (whatever volume that is in). Which ofcourse doesn't work when 
you're not standing in the coda tree. (And yes, it lacks any useful 
documentation.)

> -ben

Jan