[EMAIL PROTECTED] 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, [EMAIL PROTECTED]"
> 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 <[EMAIL PROTECTED]>
