(Illustration by Gaich Muramatsu)
On Tue, Apr 11, 2000 at 08:52:37AM -0700, Tom Unger wrote: > > I'm exploring possible distributed file systems for use by a small > development group. We are located in three different sites, connected > through VPNs routed over the internet. NFS requires too much bandwidth > to be really usable. I originally thought that the Andrew File system > might be the thing to use. When I went to look for that I found the > coda file system. It seems like a good candidate except for all the > warnings that it should not be used for "production". > > We are a small development group and can tolorate _some_ instability, > but not too much. Would coda be suitable? Coda's usability seems to vary greatly. Sometimes it looks like we've got #ifndef CMU in the code (we really don't). Our webserver serves all webpages out of Coda, but that is only a very light load. I can already think of several problems that you might encounter from the description you gave. Coda's server replication strategy assumes co-located servers. Creating a replica across 3 servers that are located at the different sites is like asking for server-server conflicts. Also Coda's optimistic replication and conflict resolution strategies basically assume that a user is behind the console. Things are done very optimistically, so there is a greater change something goes wrong (f.i. write-write sharing), in some cases these conflicts can be resolved automatically, in other cases the conflicting update is made inaccessible until the user manually repairs the problem. Initially these conflicts are very time-consuming, but people are incredibly adaptive and seem to have a knack for changing their habits which rapidly reduces the number of conflicts they have to deal with ;) (separate source and object trees, object trees on local disk, not putting ~/.netscape in Coda, etc.) Another problem is related to scalability, the biggest (known) Coda servers can only handle about 35GB of data (per server, you can at the moment have up to 252 servers). Clients start to suffer from O(n^2) algorithms with a mere 250MB local cache. These areas are currently being scrutinized, and hopefully we'll come up with a good alternative implementation for cache-replacement and hoarding that deteriorates more gracefully (or preferably not at all). > Is the Andrew File System still out there somewhere and would that be a > suitable alternative? There are AFAIK two implementations of AFS available, the commercial AFS3 from TransArc, and the open source Arla project. > I got the server and client working on a linux system. I then installed > the clinent on a lap top running win98. the client works, but 'clog' > crashes with a stack overflow. I saw someone else asking about this on > the codalist. Perhaps I could get the fix for it? We've noticed, it turns out that for some reason we get a stackfault whenever we make _any_ system calls from an LWP thread in cygwin32 cross-compiled code. Shafeeq is trying to rebuild the problematic programs as DPMI programs (yes, good old DOS to the rescue). But still, the current Coda kernel code for win95/98 seems to make the system slightly more prone to switch to the nice blue screensaver. That will probably take some more time to figure out. JanReceived on 2000-04-12 00:40:57