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. "

Reply via email to