From: Lionix <[EMAIL PROTECTED]>
>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).
Perhaps venus didn't succeed to write connect the server, made the
change in disconnected mode locally ?
No, that can't be it, because creating files on my client *do* get
shipped back to the server w/no problem. It only seems to get wedged when
files are deleted on the client.
>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]"
>
I used debian build and don't have such a way of message.....
"Coda Venus, version 6.0.3" in /var/log/venus.err...
By the way, the fact that kernel had complained for the kernel version
show that your on a 6.0.x version...
I understand this issue, now. The v5.3.18 message is from the linux coda.o
kernel module; it's not the release number of the venus client. Venus doesn't
seem to drop a message in the unix log when it comes up, so it's easy to
confuse coda.o's
Jan 16 17:50:29 mongkok kernel: Coda Kernel/Venus communications, v5.3.18, [EMAIL
PROTECTED]
message and think it was a message from venus.
Both the coda kernel module code in the very latest 2.4 kernel (2.4.24) and
the coda kernel module code in the CVS checkout from CMU have this 5.3.18
version string as of today. Venus leaves its msg in /usr/coda/etc/console, and
mine says it is version 6.0.3. So I *thought* I had a release mismatch, but I
didn't; I'm good. This logging & version mismatch is pretty confusing!
The repair code is a bit dicey. Basically, it is incorrect in spots.
I don't understand the details.
Wow! That's *amazing*; I'm suprised. Doesn't that spook people?
But with a raid array sytem you soon have a little tolerance sytem no ????
>Do you plan to replicate you raid storage servers
I'm sorry, Lionix, I don't understand your statement. Could you run that by me
again? Are you saying that with a raid array I'll have no assurance against
things like power failure? If so, the answer is that high availability is
outside the scope/budget of my little amateur server project. What I hope to
get is assurance against data loss, not assurance against downtime of server.
A limit you have to pay attention would be the maximum volume size for
backup ( 2Gb ).
I also don't understand this. Are you saying I can't back up a volume bigger
than 2Gb? Or are you referring to linux' problems with single files bigger
than 2Gb?
> + What's the current energy level of coda development these days?
Who's asking that ?
Here is about what I don't have a clear picture. The first versions of Coda
were being used by my grad school friends about the time I finished up at CMU,
in 1991. Here we are, 13 *years* later. It's very unusual for a single
research project on something like a filesystem to go on that long; typically
the life cycle of a particular research system is shorter. So my *expectation*
would be that Satya & students have moved on to other things. If true, then
who is hacking/supporting/extending coda in 2004? If falst -- if CMU is
actively driving Coda now -- that's also interesting. And if they are, why?
What's the current story? And who is paying for it? I am just generally
curious as to what is the story on coda these days, since my last real contact
w/it, as I said, was 1991.
I also note that (from perusing the sources & docs) what appears to be one
of the principal hackers, Braam, seems to have taken off to do a follow-on
project, lustre, at Clusterfs. So, again, I wonder how this ties up to the
current coda story.
When I browse around the coda web pages, I get an inconsistent picture
that's hard to put together -- some pages make it look like a dead/static
project (out of date / missing doc that hasn't been updated in years),
and other pages are vibrant & lively & thriving.
I have always (by which I mean, for over 10 years) figured coda or the
ideas in it was The Right Thing, and keep being amazed that it isn't
much, much more widely used. But perhaps the issue is the sheer size
& complexity of the system. It's not like setting up NFS on your box!
-Olin
