On Fri, Jan 15, 2010 at 9:22 AM, Marco Peereboom <sl...@peereboom.us> wrote: >> smtp ensures reliability by working on a temporary queue during writes, >> then commiting messages (all of them, including bounces) to the real >> queue using an atomic rename. after a successful rename, smtpd tells >> the client it accepted the message. > > Right and at this point you hand it off to the hardware and it does > whatever it does and lies whenever it wants to about completions, etc. > > If it is a raid controller for example, you dont know if it is in cache, > being coalesced with other IO, deferred waiting on another IO, got > reordered for some sort of optimization, partial incomplete because a > disk hasn't caught up etc etc.
You do know if you know your hardware. How is this relevant to what MTA is supposed to do? > You can do everything right all day long in software but hardware does > what it does and claiming that a piece of software is crash proof is > naive at best. I am not eluding to you Gilles, I am eluding to claims > made in qmail and parroted by someone without a name on this list. I'd > venture to say that the more magic one performs trying to force an OS > and a piece of hardware to do something without having the proper dials > is worse. Funny how these discussions quickly turn into personal attacks... Anything wrong with quoting someone? I am not making claims, the qmail's author does... He wrote qmail, it's up to him to explain what it does and doesn't do. Also, it's not the MTA's job to ensure the hardware does what it's supposed to. It neither obviously can even attempt to do that, nor is it's job to do that. I've never implied that it's MTAs job to control the kernel or hardware. It's the administrator's job to buy and configure the right kind of hardware for the MTA. It's his/her job to make sure it writes correctly to the disk. qmail's author says "Queue reliability demands that single-byte writes be atomic. This is true for a fixed-block filesystem such as UFS, and for a logging filesystem such as LFS." This implies that the FS code and the hardware does the right thing for the queue to be reliable. http://www.qmail.org/man/misc/THOUGHTS.txt http://cr.yp.to/qmail/faq/reliability.html#filesystems He also writes "You may encounter people who dispute one or more of the above statements. Those people don't know what they're talking about. A rather spectacular example appeared in February 2001, when someone wrote hundreds of lines of text in a dozen messages claiming that my FAQ was ``totally incorrect,'' claiming that the BSD FFS wrote data to disk in the wrong order, claiming that the BSD FFS was not crashproof, and claiming that qmail was not crashproof. He put a tremendous amount of effort into making his claims sound authoritative. ``I think there *might* be a dozen people in the world that understand UFS/FFS better then I do, but none of them have posted to this thread,'' he said. He repeatedly claimed that his assertions were well-known facts that had motivated the design of subsequent filesystems. Eventually, after a discussion with two people who understood FFS better than he did, he withdrew his claims and apologized. "
