Date: Thu, 13 Feb 2003 00:07:36 +0100 From: Brad Knowles <brad.knowles@skynet.be> To: Terry Lambert <tlambert2@mindspring.com> Cc: Brad Knowles <brad.knowles@skynet.be>, Rahul Siddharthan <rsidd@online.fr>, freebsd-chat@freebsd.org Subject: Re: Email push and pull (was Re: matthew dillon) Message-ID: <a05200f4cba70710ad3f1@[10.0.1.2]> In-Reply-To: <3E4A81A3.A8626F3D@mindspring.com> References: <20030211032932.GA1253@papagena.rockefeller.edu> <a05200f2bba6e8fc03a0f@[10.0.1.2]> <3E498175.295FC389@mindspring.com> <a05200f37ba6f50bfc705@[10.0.1.2]> <3E49C2BC.F164F19A@mindspring.com> <a05200f43ba6fe1a9f4d8@[10.0.1.2]> <3E4A81A3.A8626F3D@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 9:17 AM -0800 2003/02/12, Terry Lambert wrote: > In terms of I/O throughput, you are right. > > But we are not interested in I/O throughput, in this case, we > are interested in minimizing dynamic pool size, for a given > pool retention time function, over a given input and output > volume. Under what circumstances are you not interested in I/O throughput?!? I have seen some mail systems that were short of disk space, but when we looked carefully at the number of messages in the mailboxes and the number of recipients per message, there just wasn't a whole lot of disk space that we could potentially have recovered. This was across 100,000+ POP3/dialup users at an earlier time in the life of Belgacom Skynet, the largest ISP in Belgium. Virtually all other mail systems I've ever seen have not had disk space problems (unless they didn't enforce quotas), but were instead critically short of I/O capacity in the form of synchronous meta-data updates. This was true for both the MTA and the mailbox storage mechanism. > The Usenet parallel is probably not that apt. Usenet provides > an "Expires:" header, which bounds the pool retention time to a > fixed interval, reagardless of volume. Almost no one ever uses the Expires: header anymore. If they do, it's in an attempt to ensure that the message stays around much, much longer than normal as opposed to the reverse. No, what I was talking about was the fundamental fact that you cannot possibly handle a full USENET feed of 650GB/day or more, if you don't have enough spindles going for you. It doesn't matter how much disk space you have, if you don't have the I/O capacity to handle the input. > Again, I disagree. Poor design is why they don't scale. Right, and another outcome of poor design is their stupid choice of single-instance store -- a false economy. >> These slides have absolutely nothing whatsoever to do with the >> MTA. They have to do with the mailbox, mailbox delivery, mailbox >> access, etc.... You need message locking in some fashion, you may >> need mailbox locking, and most schemes for handling mailboxes involve >> either re-writing the mailbox file, or changing file names of >> individual messages (or changing their location), etc.... These are >> all synchronous meta-data operations. > > You do not need all the locking you state you need, at least not > at that low a granularity. Really? I'd like to hear your explanation for that claim. > If you want to talk AOL, AOL used to > use VMS systems, which used record locking. At what time? I worked there from 1995 through 1997, and I worked very closely with the people who had designed the original mail system for Quantum Computer Systems. The founding four came from a company where they had tried to use Tandem computers, and at that time Tandem couldn't deliver on their fault-tolerant claims. Contrariwise, Stratus could, so they build the system on Stratus. It was in 1996 that they started moving everything off Stratus and onto Unix systems. I know quite a bit about the details of that mail system, because I was materially involved in the implementation from the Operations side. I would be very interested to know at what time they have ever used any Vax/VMS systems anywhere in the entire history of the company. I have plenty of contacts that I can use to verify any claims. >> However, keep in mind that I've already had a deep discussion of >> these points with Nick Christenson (author of the book _Sendmail >> Performance Tuning_, > > Sendmail performance tuning is not the issue, although if you > are a transit server for virtual domains, you should rewrite the > queueing algorithm. My point is not that Sendmail is the issue. My point is that Nick has designed and built some of the largest open-source based mail systems in the world, and he and I worked extensively to create the architecture laid out in my LISA 2002 talk. If you look at <http://www.networkcomputing.com/1117/1117f1.html>; and <http://www-1.ibm.com/servers/esdd/articles/sendmail/>, you will find virtually the same architecture being used by the major commercial vendors for their high-volume/high-SLA clients. > See: > > ftp://ftp.whistle.com/pub/misc/sendmail/ This was written for sendmail 8.9.3, way before the advent of multiple queues and all other sorts of new features. It is no longer relevant to modern sendmail. > The Open Source book is wrong. You can not build such a system > without significant modification. My source tree, for example, > contains more than 6 million lines of code at this point, and > about 250,000 of those are mine, modifying Cyrus, modifying > OpenLDAP, modifying Sendmail, modifying BIND, etc.. IIRC, Nick talks about the changes that were required -- some, but not excessive. Read the paper. > Because Open Source projects are inherently incapable of doing > productization work. True enough. However, this would imply that the sort of thing that Nick has done is not possible. He has demonstrated that this is not true. Yes, using open source to do this sort of thing can be difficult (as I am finding out), but it doesn't have to be impossible. > $0 is not really true. They are paying for you, in the hopes > that it will end up costing less than a prebuilt system. It's a different color of money. They had already signed the contract stating that I would be working for them through April (at the earliest), before this project was dumped in my lap. So, that's not anything extra. Buying new machines, or buying software, now that's spending extra. > Contact Stanford, MIT, or other large institutions which have > already deployed such a system. I've already read much of Mark Crispin's writings. I know how they did it at UW, and they didn't use NFS. I've read the Cyrus documentation, and they didn't use NFS either. That only leaves Courier-IMAP, and while I've read the documentation they have available, I am finding it difficult to find anyone who has actually built a larger-scale system using Courier-IMAP on NFS. Plenty of people say they've heard of it being done, or it should be easily do-able, but I'm not finding the people themselves who've actually done it. >> Correct, in theory. Where's the practice? > > Not in Open Source; Open Source does not perform productization or > systems integration. Therein lies the problem. You may be able to write or re-write all of the open source systems in existence, but that sort of thing is not within my capabilities, and would not be accepted for this project. They're looking askance at my modifications to procmail to get it to use Maildir format and hashed mailboxes -- there's no way they'd accept actual source code changes. > I was unaware of this from the pitch on the billboards and WSJ > advertisements. I rather expect anyone buying it will make the > same assumptions I did, that when they were talking about making > "MS Exchange Rock Solid", they were talking about leaving it there. Which is exactly what they want you to think. Up to the point where they've gotten you to sign the contract. > 8-). As you well know. ;-) -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a05200f4cba70710ad3f1>