Coda File System

Re: CODA fail-over behavior

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Thu, 7 Dec 2000 11:24:13 -0500
On Wed, Dec 06, 2000 at 04:07:47PM -0800, Nathan Cassano wrote:
> Hey CODA folks,
> The last two days I've been working on setting up CODA replication for our
> two web servers. One server is the scm and the other non-scm. I've setup
> replicated volumes that work when the conditions are right. The problem I
> run into is when either of the servers is disconnected or rebooted the
> /coda/volumes/files become read-only or inaccessable. Isn't the client
> supposed to try the next server if one goes down? I'm using 5.3.9.

Yes, it is supposed to do that, however.

When you make any modifications to the filesystem while disconnected,
the changes are not propagated back to the server until the user who
modified the volume has valid authentication.

For several reasons this is even necessary when the changes could have
been made by unauthenticated users (i.e. when directories are writable
for System:AnyUser).

You can check the state of the volume using
 `cfs listvolume (lv) /path/to/read-only/volume'

It probably says something like "xxx CML entries pending reintegration".


The other reason for a volume to become readonly after disconnection is
when there is a conflict, which occurs when the same files were modified
by different clients during a disconnection. As the fileservers don't
know how to `merge' the contents of arbitrary files they will mark the
object in-conflict and it shows up as a dangling symlink such as

lr--r--r--  1 root      27 Mar 23 14:52 conflict -> @7f0000b3.00000005.0000011a

This will need to be repaired using either the repair tool (for
server-server directory and client-server reintegration conflicts), or
filerepair (for server-server file conflicts). For more details on how
to repair conflicts, read chapter 2 in the Coda File System Users and
System Administrators manual (http://www.coda.cs.cmu.edu/doc/)

Jan
Received on 2000-12-07 11:24:30