On Fri, Jan 16, 2004 at 06:30:22PM -0500, shivers_at_cc.gatech.edu wrote:
> 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

Correct, the '6.0' patch never fixed the version number. In the patches
that were merged in the official 2.6 kernels this is already correct.

It is a bit confusing either way because the kernel version never really
matches the current userspace version. So even if the kernel says
5.3.18, that doesn't really mean that the kernel would have a problem
with a 5.3.17 or 5.3.19 version of the userspace stuff.

But using something like 'Coda v5 vs. Coda v6' won't help, because there
was no really big change between f.i. 4.x.x and 5.x.x except for a
licensing change on the userspace code (I believe mixed BSD(ish) with
some LGPL libraries, to GPL/LGPL everywhere).

The 5.x to 6.x change was pretty significant for both kernel and
userspace code on the client, but the client<>server protocol remained
unchanged. There are simply too many dependencies to put a logical
versioning number on anything, the only thing we can do is to keep
things as compatible with previous versions as possible and have an
occasional 'break everything' event.

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

Not really that much, repair problems fall in different categories.
First of all we're doing things that the kernel would not normally
expect, when a conflict is detected, the file or directory is turned
into a dangling symlink. This is kind of an evil operation as far as the
kernel is concerned because the file or directory might still have
active references. Then when repair is started the symlink is changed
into a directory, but the object that used to be the conflict is then
'reparented' underneath this fake repair directory, but this expansion
is different when there is a resolution conflict instead of a
reintegration conflict. Because of the differences we can't currently
repair a local-global (reintegration) conflict that occured as a result
of a server-server (resolution) conflict.

Then, when repairing reintegration conflicts, the actual problem might
be hidden in a previously removed subtree, which could even be obscured
by some object that was created after the remove. (i.e. rm -rf foo ;
touch foo) So there is a lot of messy code that tries to reinstantiate
the image of some tree from the past to show during a repair session.

All in all repair (and resolution) are Coda's most complicated features,
disconnected operation/logging/reintegration seem almost simple in
comparison. But as they are the most complex and, if everything goes
right, the least used, they do contain a lot more areas where things go
wrong.

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

Hmm, some clarity would probably help here. It is possible to back up
volumes larger than 2GB, but... The underlying OS/filesystem need to
allow for larger than 2GB files and you can't allow volutil to
read/write the file directly but have to pipe through stdin/stdout.

The second condition means that the coda-backup package/scripts
essentially do not work for >2GB volumes. But it does work if you use
f.i. a slightly modified version of Amanda, which is what we use here at
CMU.

>     > + 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

I guess Satya already pointed you at the 'Evolution of the Coda File
System' paper. In my eyes, Coda is transitioning from being the main
research effort in itself to becoming a vehicle (framework) to carry
other research projects. Satya & students have extended their scope to
other things, like Odyssey/Chroma, Internet Suspend Resume (Intel
Research), etc. But in some ways these project build on top of, or
provides services to Coda.

> 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!

I agree, Coda does have a lot of potential, but is still very complex in
many areas. Installation is the first hurdle although client setup is
starting to become relatively trivial. Then there is the fact that Coda
has a very different (not-Unix or Windows-like) semantic model. We're
using traditional AFS semantics, which intriguingly enough AFS isn't
using anymore :) and directory ACLs instead of Unix user/group modebits.

And this short list doesn't even include server administration and
repair/conflict resolution related complexity, just end-user complexity.
Maybe Coda isn't the solution (yet) for everyone in all situations there
are several alternatives like rsync/unison/cvs/nfs/samba that are easier
to set up and can do the trick for many people, but in other areas Coda
is still the only solution. We just have to make it even better.

Jan