At 12:17 AM +0100 2004-10-22, Richard Barrett wrote:
1. handling of files containing messages queued for processing as they are moved along the chain of queues from initial delivery by the MTA to handoff to the outbound MTA and to the archiver. The code in $prefix/Mailman/Queue/Switchboard.py provides the enqueueing and dequeueing functions.
That's fine once the message gets to Mailman. This means that your MTA queues (and probably your user mailboxes, unless you use an NFS-friendly storage method for them as well) should be on local filesystems, however. If the server goes down, you risk losing those messages which are in the MTA queue but haven't been delivered yet.
It appears to me that the operation of this code avoids dependence on file system locking during both file creation and deletion and is intentionally unaffected by a decision to use NFS mounts as the storage for Mailman's qfiles.
If Mailman does work this way, then this is very good news.
The residual risk is of collisons in generating the file names of queued messages files using SHA digests but I think this is fairly small.
Agreed. Since we're not talking about crypto applications here, we could probably even use MD5 hashes reasonably safely without having to worry too much about the unlikely collisions.
2. handling of files containing per list related data structures and productions of archiving processes. These operations are protected by a list locking scheme implemented using the code in $prefix/Mailman/LockFile.py The comments in this module suggest that specific efforts have been made to avoid deficiencies associated with NFS mounted file systems but there are cautionary notes such as ensuring that clocks on the systems concerned are adequately aligned.
Also good news. Also points out another known issue with NFS filesystems, and good server timesync is a very important issue that I am also involved with (see <http://ntp.isc.org/bin/view/Main/ContributorsList>). Indeed, it was my involvement with NTP that brought me to Mailman, since we were running our mailing lists at the time with Majordomo and I wanted to move to something that would be easier to manage.
My own, non-expert conclusion is that
a. Switchboard.py's code sidesteps any requirement for fine grain locking of individual message files when the are being queued and dequeued and this avoids deficiencies NFS might have in this respect.
That is a likely conclusion.
b. The coarse grained locking used for protecting per list related data structures and archiving operations specifically addresses known deficiencies in NFS.
Also likely.
It seems to me that your reservations are reasonable but it is clear that the authors of this part of Mailman (all smarter men than I) were conscious of the potential problems and have made efforts to avoid them.
Barry (and the other Mailman developers) are most certainly not dummies, but I wasn't aware that this was an issue that they had specifically looked into carefully and make significant efforts to try to deal with.
This is very, very good news.
Thanks for the update!
-- Brad Knowles, <[EMAIL PROTECTED]>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755SAGE member since 1995. See <http://www.sage.org/> for more info. ------------------------------------------------------ Mailman-Users mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
