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