(Illustration by Gaich Muramatsu)
shivers_at_cc.gatech.edu writes: > The best thing linux has going for it is mindshare & energy. It is the most > popular / aggressively-developed thing because it is the most popular / > aggressively-developed thing -- snowball effect. I am well aware of the code > maturity and careful design on the BSD side of Unix, and the consequent > advantages particularly for servers. I was just wondering if the coda > development effort had succumbed to the gravitational pull of the linux > phenomenon. (This is not to diss linux; it is a fine thing and I run it.) Absolutely. I would choose Linux if I cared most about openoffice/java/etc. But for most things I choose NetBSD. As for the fear of things only supporting Linux, that is a reasonable concern but here on the list a number of us keep testing/running on BSD and I think some of the CMU servers are NetBSD or FreeBSD. > I have seen something like this on my test setup, which is an old > (2y) BSD server (FreeBSD 2.5) with old coda server built from the > ports collection, and the latest coda client (I think; see below) on > my linux notebook. What happens is a bit mystifying. I can mount the > filesys, make files, see them, everything is good. Then I delete a > file on my client and suddenly coda gets quite unhappy, dropping a > conflict packet in /usr/coda/spool (an empty tar ball & a cml file > listing the delete op). Then it bitches about inconsistent or > unresolvable hoo-ha. If I try to run repair(1), beginrepair refuses > to acknowledge there's a problem, claiming "Could not allocate new > repvol: Object not in conflict." So I'm hosed until I nuke the > entire client setup with a big hammer like venus-setup and start > over. Coda has changed a lot. I would upgrade everthing to the latest CVS. Note that you'll need to 'pdbtool export' before upgrade and 'pdbtool import' just after; the db format changed. And venii need reinits, but other than that it should be ok. There was a bug with singly-replicated (i.e. one server) servers, and you might be hitting it. > I *don't* lose when I'm using venus locally on the BSD box, which is the > older client -- the whole coda setup on the BSD box was built from the > ports collection that came with the OS (FreeBSD 4.5). You are in connected mode I bet. > I figured this was due to client/server skew, what with the old coda > server & the new coda client, and was going to upgrade the server. But > that's just a guess. Now I see your comment about fake conflicts due to > thin-pipe write disconnects. Can someone tell me why this happens? The repair code is a bit dicey. Basically, it is incorrect in spots. I don't understand the details. > - (I'm running RedHat 9 w/a 2.4.24 kernel) > - I compiled my kernel with coda support. > - I installed the rawhide rpms from the coda download site: > lwp-1.10-1 > coda-client-6.0.3-1 > rpc2-1.20-1 > rvm-1.8-1 > rvm-tools-1.8-1 > - I lost due to the "your kernel is too old" err msg when venus came up. > - I patched the kernel sources with the linux-2.4-coda.patch from the coda > download site & recompiled. > - Victory. > Is this the righteous path? Reasonable. I compile lwp/rvm/rpc2/coda out of CVS. > What is a little confusing to me is that the client rpm is named > "coda-client-6.0.3-1" but when venus comes up, it says > "Coda Kernel/Venus communications, v5.3.18, coda_at_cs.cmu.edu" > 5.3 seems a long way from 6.0. Are venus release numbers distinct from those > used for a larger "coda client" package entity? Should be the same. Mine says 07:38:15 Coda Venus, version 6.0.1 (note that I'm a tiny bit behind on this box) -- Greg Troxel <gdt_at_ir.bbn.com>Received on 2004-01-15 13:29:50