Coda File System

Re: New coda deployment

From: Ivan Popov <>
Date: Wed, 28 Apr 2004 11:35:07 +0200
Hi Mike,

On Tue, Apr 27, 2004 at 01:30:45PM -0400, Mike Pelletier wrote:

> else.  I'm prepared for a few headaches, what I'm worried about are
> the potential show-stoppers that I might not be seeing.  I'd sure

> We would like to replicate the mailboxes and web folders for up to
> roughly 33,000 users.  (The initial requirements would be 1/10 - 1/100
> of that.)  There will be two hosts acting as mail servers, and two

Be aware that Coda currently (and possibly for a long time in the future)
can not handle directories longer than about 7000 entries (iirc).
Placing mail messages in separate files can easily exceed that number,
for a single user mailbox.

> Is maildir still the state of the art?  I think there are other

Yes, afaik. I am fetching mail to maildirs on Coda and managing it
with mutt.

> one-file-per-message formats.  Are they more likely to generate
> collisions and conflicts on Coda?

I am not aware of another format suitable for concurrent updates
without locking. As Coda does not offer any locking, it seems to be
the only option. Well, it should be the best option on any distributed
filesystem, as distributed locking is a pain.

> What maildir delivery and mailbox software is known to follow the de
> facto standard?  If I have to test a new package, what actions use

tested: fetchmail delivering via procmail and mutt as MUA.
I think any reasonable maildir implementation should/would
be able to use rename in place of link-unlink.
I did not need to fix either procmail or mutt.

> we'd like it to deliver any mail it gets right to the shared maildirs.
> That way users can still get to email that comes in during an outage
> of the primary server.  Is this a completely stupid idea?  Will it
> "just work" or am I going to have to do some hacking?

It should be able to work - though never tested.

> Lastly (for now), we pretty much have to avoid exposing coda conflicts
> to the end user.  I'm still shaky on manual conflict resolution, so

Conflicts are logically inevitable as soon as you want the optimistic
replication and read-write disconnected mode work.
Worse, there are still some situations when Coda proclaims a conflict while
it is avoidable. You can not hide a conflict when it happens, the file
or directory becomes inaccessible (and subsequent updates from a client
may not propagate to the server until the conflict is resolved)

> care of conflicts via policies, or some other mechanism.  The manual
> suggests conflict resolution can be automated for some cases, but it

Right now conflict resolution is messy. There have been plans to totally
rewrite the tools but I do not know what and when will be done.

> It seems to me that, so long as I can make sure there cannot be
> multiple mailreaders active on the same volume but on different hosts,
> there is no possibility of a conflict, no matter what the (assumedly
> sane) mail delivery agents may do.  Is this so?

Unfortunately, in some situations you can get conflicts even while
updating from one and only client. It sounds almost irrational, but on the
other hand it is pretty hard to eliminate. Hope it will improve.

> The other conflict scenario I see is when the user attempts to update
> their web folder from both hosts at the same time, or (more likely)
> wants to run a .cgi which modifies files in their volume.  I'm a bit
> concerned about this one.

To make it clear - there is no locking on Coda, so independent updates
from two different clients will lead to conflicts sooner or later. Very soon.
(you _will_ have to serialize "parallel" updates in some way...)

> cover every detail, I just want a little reassurance that what I'm
> attempting isn't begging for problems.

I believe you are going to face problems.
Coda is definitely not meant to be used for parallel updates.
I think the only way to possibly succeed with a project like yours would be
contributing to Coda development to make all the necessary fixes and
additions (like a nice interface for resolution), and acquiring lot
of understanding of Coda details, to design your system in a compatible way.

Coda can be usable in the environment like you describe, but not
out of the box.

My 2c
Received on 2004-04-28 05:44:08