On Sun, Jan 04, 2004 at 12:02:51PM -0500, Samir Patel wrote:
> I've been using a coda client that hasn't had the cache "flushed" in a
> while.  However, I think I have a problem now.  Running codacon, I get a
> lot of the following:
> 
> NewConnectFS viotti.coda.cs.cmu.edu ( 11:57:51 )
...
> ValidateAttrsPlusSHA Repository(55251788.7f000558.3320.14454) [50] (11:57:51)
...
> unreachable viotti.coda.cs.cmu.edu ( 11:58:06 )
...
> I'm pretty sure this is a result of my trying to have cd'ed into
> /coda/coda.cs.cmu.edu... or something like that.  But now I don't want

That in combination with most likely an updatedb process that isn't
excluding /coda, and as a result will try to build an index of the
complete tree. Add /coda to PRUNEPATHS in /etc/updatedb.conf with
RedHat's slocate there is probably some other file.

> venus to try contacting these servers, venus is even trying to contact
> servers that no longer exist.  I could resolve this problem easily by

Nah, the servers exist, but it looks like you have a firewall that drops
the reply packets. Are you connecting through a masquerading firewall?
It looks like the server is able to send a few packets back, just enough
to set up the initial binding but fails to receive the ValidateAttrs
request (or is unable to reply with anything substantial) which is
triggering the disconnections.

ValidateAttr rpc calls are pretty much the largest packets we send and
are typically sent as fragmented UDP packets. If your firewall blocks
UDP fragments, then you could lower the number of files we validate at
one time by changing the 'validateattrs=' option in venus.conf.

If the firewall is masquerading (i.e. Linux netfilter) you might also
need to make probes faster, as that will keep the connection alive.
Normally UDP redirections are dropped within about 3 minutes.

/etc/coda/venus.conf

    validateattrs=21
    server_probe=150

> flushing the cache, but I don't want to do that.  Is there anything else
> I can do?

cfs fl /coda/coda.cs.cmu.edu should do the job of only pruning the
cached files from the coda.cs.cmu.edu domain. If nothing references the
files they would also get discarded over time. However there was a
refcounting problem on volume mountpoints introduced around 6.0.1 which
is keeping the root of every volume alive no matter what. I believe only
CVS has a fix for that, so the cfs fl trick won't be able to completely
get rid of the realm mount and you need to reinitialize venus.

Jan