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.

Jan