I can second most of what Phil said (except NT that I don't use).
I've been running coda for a long time (6 years?), and haven't lost
data on the servers.  Clients (program 'venus' that manages cache) get
confused at times, but generally only when operating in disconnected
or write-disconnected modes over thin pipes.

Problems:

  Coda is not 64-bit clean.   It does work on i386 and sparc.   In
  theory one could run 32-bit sparc userland binaries on sparc64, if
  the kernel code (sys/coda/*) is 64-bit clean, and it is probably
  close.

  The kernel code probably has some locking bugs, but they are hit
  rarely.

  The server-server protocol seems to not be endian-clean.  I have
  heard reports that having servers for a given volume on cross-endian
  machines doesn't work.  (Clients and servers can certainly be
  different endianness - I've used sparc clients on i386 servers.)

  THe servers can only store so much data.  Limitations are in number
  of files (due to limited metadata size, which is all mapped), and in
  the size of each directory (so having all internet-drafts in a
  directory doesn't work - but that's roughly where the limit is).

  Disconnected operation is a bit dicey, but not much.  Don't 'rm -rf
  foo' while disconnected, etc.  - do major cleanups on a
  well-connected client.

  Coda uses 'lwp', which is a cooperative thread package.  It may not
  work everywhere, but they are moving towards being able to use
  pthreads.  Perhaps they can already.  It works on the platforms I
  have (i386 and sparc), so I haven't worried about it.

Pro:

   You can read files on a client while not on the net, and change
   them, and have them written back when you return.   After setting
   up a 'hoard list', the client will poll the server for new/changed
   files and grab them while connected.

   On thin pipes (28.8k), trickle reintegration of changes
   (write-behind caching) can fail, leaving the client wedged.

   In a coda setup, someone really has to want to play with Coda.
   It's not like NFS where you just set it up and it works.  Users
   shouldn't need to become coda weenies, just one person to solve
   hard conflict problems.   The server is quite low hassle once set
   up.


It's true that the main developer runs Linux mostly, but almost all of
the code is os-independent, it's autoconf'd, and the NetBSD kernel
code is in pretty good shape.  So I wouldn't call it a Linux-centric
project.




Note that pkgsrc bits are ancient and you want to compile coda from
the coda project's anoncvs, or at least recent releases.  You need GNU
readline installed first.

#!/bin/sh
for i in lwp rpc2 rvm coda; do
  echo "BUILDING $i" && \
  (cd $i && \
  ./bootstrap.sh && \
  rm -f config.cache && \
  LDFLAGS="-L/usr/pkg/lib -R/usr/pkg/lib" CFLAGS="-g -I/usr/pkg/include" CXXFLAGS="-g -I/usr/pkg/include" ./configure --prefix=/usr/local/coda && \
  gmake -k clean && 
  gmake -k &&
  gmake install)
done
(cd coda && gmake -k client-install server-install)
exit 0



-- 
        Greg Troxel <gdt@ir.bbn.com>