(Illustration by Gaich Muramatsu)
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. JanReceived on 2004-01-19 15:12:57