(Illustration by Gaich Muramatsu)
Hello, seeing some points I'd like to comment on (my problem with upgrade from .11 to .12 miraculously went away after I rebooted all servers several times to get fresh logs for Jan, now it's just tons of repairs, thanx still :). > There are several big hurdles we have taken and still have to take to > get Coda nicely integrated on Windows platforms. Maybe focusing on NTs/2Ks would make more sense ? I mean, I don't see much point in trying to bend over backwards to accomodate an outdated virtual machine concept ? > The only effect that clock skew has is when applications that use RVM > are restarted and the time has warped back. The client-server > interaction has definitely no time dependent parts, we wouldn't even > dare consider calling this a _Distributed_ File System if it did. I have different experience here. I had definite problems when one of the replicated servers had a date set one day back compared to all the others. Mostly it was loosing authentication tokens some time in the middle of working with the volume (empirically, it was when the one server with wrong time figured the token should expire), which caused "false" conflicts to appear, and made the system basically unusable. After syncing all with NTP the problems went away. Also, seeing how Jan really reads this, I thought to add a few more observations: I definitely agree the documentation should be updated. At least the "quick install" guide. What I personally missed in my hmm, month or so ? with Coda, was: - Outdated installation instructions. In the end, it turned out to be just "rpm -U coda*.rpm", but I kept worrying if it is really so easy when all the docs says things should be started manually (not through rc.d scripts) etc. - Also, I tended to get myself lost in the various IDs used. After several adds and removes of volumes, I kinda figured it out, but a few lines in the docs (e.g. that one is supposed to come up with IDs of groups for VSGDB) would help. - The documentation seems to give the system a more unstable feel than it probably deserves. One example I recall is the private mmap support, which I did not dare try due to warnings in the config file comments, but switched to after I saw a message here that suggested it should work OK, and it was a great improvement (one of my servers is low on memory and this helped a lot). I also encountered the problem with local vs. fully qualified hostname. What seems to work is keep /vice/hostname short and names in server list and everywhere else long. This is something one has to do manually after install. There are bugs in scripts. At my servers, purgevol_rep (or whatever is the script for deleting volumes called) fails, obviously looking for some list of volumes that does not exist in the current version. This, however, was all things one could kinda sorta work around. What I have a biggest problem with is the repair tool. I run three servers in an environment where very often, one or two are inaccessible (but there are never concurrent updates from more clients). When conflicts occur, the repair tool often fails to fix them, and I usually end up with doing "beginrepair", copying all the copies somewhere else, doing "removeinc" and copying the data back (sometimes, "removeinc" fails on one server but not on another, etc.). --- BUT ! It still seems to work and is usable ! (at least on my platform, I really didn't try Windows) The questions I'm running into now are more of the sort, is Coda really the system I was looking for in my particular situation ? I have three machines I work on, geographically distant and not always connected very well. I used to have a script that used rsync to keep the home directories synchronized, but this was not really reliable (rsync has problems with links, changes that involve modifying directory structure, and bidirectional updates, among others). I switched to Coda, and made all the three computers servers (in hope of having the updates always propagated to at least one server when the network is down). This seems to work nicely, except for the following: - I have to use write disconnected mode, otherwise the delays in propagating the updates to all the servers are too big. In that mode, however, conflicts appear much more often (and even in situations where I don't think they should). - Some of the files I have are logs, of several megs in size, that only get appended to. In the write disconnected mode, it seems that the updates are propagated in form of entire files, not just change logs, which means huge amounts of data get passed over the net for even small changes. (Just a hunch looking at the network traffic.) - I use up twice as much disk space, because I have both the client and the server running on a machine where I'd normally have just one copy of the data. Now, did I pick Coda right, or am I trying to use it in a situation where something else (what ?) would be better ? Petr TumaReceived on 2001-01-28 17:28:33