Coda File System

Re: volume connection timeouts

From: Ivan Popov <>
Date: Mon, 2 May 2005 20:21:32 +0200
On Mon, May 02, 2005 at 11:30:32AM -0600, Patrick Walsh wrote:
> > Even neglecting vmware overhead, you let client and server compete
> > for resources like memory and disk access (and they are rather picky
> > about syncing data to disk). It make disconnections probable.
> 	Really?  Our server farm design pretty much requires the backend
> machines that act as coda servers to have coda clients running as
> well.  

Well, I would not run anything besides a Coda server on a machine.
Why would you need a client there? Are you going to run web servers
on the same machines as Coda servers, or run Coda servers on workstations?

> Removing the conflict has fixed everything, but raises the question:
> with only one client and one server and both strongly connected, how
> does a conflict happen and how can it be avoided?  

It is a known issue, something for FAQ...
It is hardly possible for a client and a server to guaranteedly
have the same view on which transaction succeeded and which did not.
In some situations a reintegrating client has to guess, and sometimes
it is wrong.

> 	If the vmware machine had more memory do you think we would stop seeing
> these problems?  The production machines have 1gb of memory and plenty


> of power.  Is there a way to make coda a little more tolerant so that it
> doesn't slip into disconnected mode unless there's actually a
> disconnection?  Our architecture is such that there should never be two

It is possible to influence to some degree, but never have it guaranteed.
Or looking from another perspective, you do not want the clients to wait
forever when a server goes down.

> machines (or two coda users) who edit the same file.  Most coda clients
> will be read only for most volumes.  Getting conflicts when there is
> only one user, one client, and one server all strongly connected is a
> bit baffling.

It looks surprising but it is the reality - you can get a conflict
with one client and one server. Jan has improved it but still
there is an area of uncertainty when either the network drops packets,
or either the servers or the clients are slower than expected by the peer.

Received on 2005-05-02 14:22:56