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>