On Thu, Jul 17, 2003 at 11:35:35AM -0400, Ken Price wrote:
> 1)  Disconnected Operation:  If the CODA server dies (or I reboot it), will
> the client machines still keep working off their locally cached copies of
> the files?

Yes

>             Will the client have a complete mirror of the files cached
> locally, or only the ones already accessed by the webserver?

A client will normally only have previously accessed files in the local
cache (otherwise it wouldn't really be a cache :) However, it is
possible to set a 'hoard profile', which instructs the client to treat
files as sticky. Files that match the hoard profile are among the last
ones to get purged from the cache, and they are automatically fetched
during the periodic hoardwalks (f.i. when they have changed on the
server).

I typically keep my email folders and the Coda webpages hoarded on my
laptop.

> unavailable?  When the CODA server comes back online, are the cached files
> still available to the web server while CODA checks for updates?

Yes, while validation happens in the background, access is still
possible.

> 2)  Stability:  I see this asked alot in the archives, and there are always
> replies along the lines of, "Yes, but only in this XYZ configuration."  So

Hard question, things seems to be fine a lot of the time, but sometimes
the same operation hits a bad piece of code and all bets are off.

f.i. our webserver serves almost all html pages out of Coda, we even
have the mailinglist archives stored there. However the webserver is an
older PII 200 with 128MB of memory, and the hypermail indexing pushes it
about 500MB or more into swap. We had numerous disconnection and
reintegration problems when hypermail was writing directly into /coda,
venus gets mostly swapped out and doesn't page back quick enough to send
a reply to the server. So I've configured hypermail to write to the
local disk and rsync is used to update the copy in /coda. This works
well most of the time, but sometimes something else (htdig/updatedb?)
is kicked off by cron and we still end up with unwanted conflicts.

Hypermail runs every 15 minutes, and about every other day, the codalist
archives are not accessible until I fix the resulting conflicts, Coda
keeps running and still allows access to other areas and such, but we're
not getting anywhere close to 24/7 on /maillists/codalist.

On the other hand, as this is causing me so much personal grief, it is
one of the areas that will get fixed sooner than later ;)

> 3)  Robustness:  How efficient is a CODA solution?  I played with it back in
> October of last year, and my two 650Mhz Athlon machines with 256Mb RAM were
> pushed hard under only moderate load when running as both RW client/servers.

It depends on what you consider moderate load. Our testserver has about
70 clients connected with about 1-2% CPU usage, it is a P90 with 64MB of
memory. The 'production servers' are PII 200's with 128MB and between
220 and 330MB of RVM. They are idle most of the time.

The fact that clients agressively cache means that servers rarely see
actual file fetches. Only files that are written will have to be read
by interested clients, but we don't see all that much active sharing
between various clients.

> In this scenario, do the members of this list see any major advantages of
> using CODA as it stands presently (6.0.1?), over the current version of
> OpenAFS (1.2.9a) on a RedHat 9 machine?  Since I am only talking Read-Only

OpenAFS should be more stable, it clearly has had a longer time to
mature. Coda development probably started around the same time that
TransARC stabilized and commercialized AFS, and Coda is based on the
research version and probably has had fewer man-hours, most of which
were put towards developing Coda's features as opposed to fixing bugs
reported by customers. Only in the past couple of years has the main
development effort shifted towards making Coda more reliable and
portable.

Jan