(Illustration by Gaich Muramatsu)
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 -- IvanReceived on 2004-04-28 05:44:08