(Illustration by Gaich Muramatsu)
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."Received on 2001-07-03 08:45:18