(Illustration by Gaich Muramatsu)
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. JanReceived on 2003-07-19 14:25:39