Coda File System

Re: stability

From: Jan Harkes <>
Date: Wed, 28 Nov 2001 14:02:54 -0500
On Sun, Nov 04, 2001 at 10:59:46PM +0100, Christian Hammers wrote:
> As this point in the general section of the FAQ is hopeless outdated 
> (1998) and the last entry in the mailing list is from january, I would 
> like to ask how good coda is currently in terms of stability.

Sorry for the late response,

Coda's stability varies and depends a lot on the type of usage.
Read-only operation is pretty stable by now, our webserver has been
serving all it's pages out of Coda for at least a year or two without
serious incidents. It only writes occasionally, to keep the mailinglist
archives updated (every fifteen minutes) and to update the glimpse
search indexes (twice a day).

Read-write disconnected or write-disconnected (i.e. when logging write
operations) still has some bugs that surface occasionally.

However most problems that occur stem from the different semantics
compared to traditional UNIX filesystems, i.e. Coda only propagates
updates after a close, which is sometimes surprising, especially because
some applications like samba or webservers cache open filedescriptors
and updates never arrive at the server.

Another thing is optimistic replication/caching strategy both between
servers and between a disconnected client and the servers. This allows
for a faster and simpler implementation without distributed locking, but
also opens a window for conflicts between file versions. Some conflicts
can be automatically resolved, such as different files created in the
same directory. However some require user intervention, i.e. different
files created with the same name in the same directory. This can limit
usefulness for a Coda client that doesn't have a regular user, for
instance a Coda client that re-exports /coda using Samba or NFSd
read-write but has no actual logged-in users that can fix potential

Received on 2001-11-28 14:03:07