Thanks for the replies.

   > - Would coda have trouble with large filesystems, in the range 600Gb - 1.5Tb?
   >   (E.g., a raid)

   There is a limit on RVM size, which holds metadata.  So for moderate
   numbers of huge  files it will be ok, but not huge numbers of moderate
   files (this is all per server).  See the  spiffy new 'rvmsizer'
   program in coda CVS.

I'm planning for moderate numbers of big files, so it sounds like I'll be OK.

   > - If I were to set up a coda server, and I was just as willing to run
   >   Free/Net/OpenBsd or linux, is there a best candidate?

   I would run NetBSD.  As a coda server, the real issue is 'anonymous
   rvm mapping', and I think that works better on BSD.  But others can
   speak up and that may not be an issue any more.  Aside from that, I
   think it's easier to deal with, more reliable, etc. but  that doesn't
   have anything to do with coda.  There is also the issue of the
   underlying fs for the coda files, and stability.  I don't know about
   reiserfs, but I recall that with ext2fs the norm is to run async which
   means no ordered metadata updates.

I have huge reliability issues w/reiserfs. I don't need what it does well,
and I find its down sides very troubling.

Ext3 fixes the big problem w/ext2, but mount times for really big disks
are shockingly long. Softupdate BSD seems like the current best choice.

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.)

   >   + Were one to choose between lustre, coda & intermezzo, can anyone
   >     give me a rough picture of the tradeoffs? 

   Coda works mostly ok, except that when you are write-disconncted over
   a thin pipe (28.8k) you will lose often with repair fake conflicts
   that require a full client reinit.

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.

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).

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?

   I don't think this is the case.  Basically no one here has played with
   it, I suspect.  The problem with systems like this is that they
   require a significant investment to understand them and set them up.
   I've been running coda since 1997 or so, and would be inclined to play
   with intermezzo, but haven't had spare time or motivation.  I also
   have the impression that it is mored tied to Linux.  Being a BSD
   weenie, the lack of BSD support is a big drawback.

Yeah, lustre's name is derived from "linux clusters," so that tells you
something. And the lustre download page offers only linux stuff. But it can't
possibly be true that the *clients* are limited to linux; what would be the
point? Maybe I missed something, or Win clients are coming, or something.

I'm a little confused about coda release numbers. I built my linux client this
way:
  - (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?

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?
    -Olin