After the recent rash of success reports for Coda 5.3.15 on NetBSD
1.5.1alpha, I thought I'd give it a go.  Some observations:

(1) In my initial setup, I got the Missing/Invalid thing.  For future
reference, other symptoms of cache too small seem to be

14:35:49 MAX_SW_ITERATIONS reached, SuspectCount=2048!!!

on the venus console when hoarding, and blizzards of

[ H(06) : 0000 : 14:23:41 ] fsdb::Create: (7f000002.357e.2065, 7500) failed

in venus.log.  This drove me up a wall until I remembered:

>>>>> "Jan" == Jan Harkes <jaharkes_at_cs.cmu.edu> writes:

    Jan> Is the amount of data you are trying to hoard greater than
    Jan> the venus cache size?

Yep, I was.  Thing is, I _know_ that the stuff I want to look at in
/coda are all small files.  I'd like to keep venus's use of VM to
something reasonable (say 100MB, but 20MB or less probably wouldn't
bother me given the usage pattern, looking up about 2 dozen files at a
time, I probably wouldn't use a fifth of that).

But I'd also like to hoard a big hunk of stuff (XEmacs and
the lecture notes alone account for 365MB).  Is there a reason why
hoard size can't be decoupled from RVM size?

(2) hoarding generates a lot of output (about 10000 lines at a shot,
both when building the hoard and then again repeatedly when checking
it later) in venus.log, like

[ H(06) : 0000 : 14:23:47 ] binding::~binding:  somebody forgot to decrement before delete
[ H(06) : 0000 : 14:23:47 ] binding::~binding:  somebody forgot to decrement before delete

Is this known?  (NB, I guess I'm jumping to conclusions about the
later batches, I haven't tried running without a hoard yet.  But the
first spew waits until I've set up the hoard and started the walk,
then it gushes right out.)

(3) I'm seeing these occasionally while building the hoard:

17:51:14 DispatchWorker: signal received (seq = 87621)
pioctl:Walk(0): Interrupted system call

(4) As mentioned before, I had to create /dev/cfs0 by hand.  I did use
venus-setup.  NetBSD's MAKEDEV seems to take its argument pretty
literally; I do have a (useless) /dev/cfs which is what the current
version of venus-setup says to create.  (I guess I should remove
that.)  Dunno about Linux/FreeBSD/whatever, you may have to special-
case NetBSD here.

(5) venus generates literally millions (I am not making this up, I
counted with grep | wc) of each of the following kinds of messages
over a 24-hour period with a reasonably large hoard (about 4000 files
in my case):

  - "binding::~binding:  somebody forgot to decrement before delete"
  - "SetValidCache"
  - "RecordReplacement(1,0)" followed by "RecordReplacement complete."
  - "fsdb::Create: (...) failed"

The last two seem to be related to the cachesize too small problem, as
venus continuously tries to update everything.  The first two seem to
occur as long as there's a strong connection (I haven't tried
disconnecting yet, I wanted to get my hoard populated first).

200 MB log files in less than 24 hours are considered a DOS attack in
some circles, you know.  ;-)  AFAIK I did nothing special to request
this verbosity.  I assume that "venus -d <sufficiently low>" will shut
it off (I do want logging until things seem to be working OK), but I
was a little taken aback by the default!

Installation info:

Server is Coda 5.3.10 (need to update that, huh?) on a remote Linux
2.2.18, Debian distro (sid) system.  PII 450MHz.

Client in question is Coda 5.3.15 (CVS 5/26) on NetBSD 1.5.1alpha, CVS
current 2001/3/6.  I've updated NetBSD since then but I think that was
after my last kernel rebuild on 5/25 -- kernel could be as recent as
5/25 CVS though.  No server on that box.  PII 650 MHz.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."