On Fri, Jan 15, 2010 at 08:22:56AM -0600, Marco Peereboom wrote: > On Fri, Jan 15, 2010 at 09:55:30AM +0100, Gilles Chehade wrote: > > On Thu, Jan 14, 2010 at 05:09:03PM -0500, nixlists wrote: > > > On Thu, Jan 14, 2010 at 4:26 PM, Denis Doroshenko > > > <denis.doroshe...@gmail.com> wrote: > > > > On 1/14/10, nixlists <nixmli...@gmail.com> wrote: > > > >> Does it have the same reliability features as qmail on an FS without > > > >> softupdates? What about with softupdates? > > > >> > > > >> http://cr.yp.to/qmail/faq/reliability.html > > > > > > > > the very link you just provided contains the following sentence: > > > > > > > > Do not use async or softupdates filesystems. > > > > > > > > > Sorry, forget I mentioned softupdates. Does it do what qmail does? > > > Reliaibility-wise? > > > > > > "qmail's queue, except for bounce message contents, is crashproof on > > > the BSD FFS and most of its variants. " > > > > > > > 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 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. > > > with this ordering, you can never have smtpd in a state where it has > > lost a message after accepting it or where a message is incomplete and > > corrupt in the queue because of a power shortage happening at a wrong > > timing. either the message is in queue or it's not, and if it's not > > then client/mua was not told message is accepted. > > You forgot to add the word, theoretically, to the prior sentence. >
it was implied by your previous post :-) i was just decribing what smtpd from a code point of view. smtpd does it best and i believe it is no less reliable than qmail or postfix wrt handling of messages in queue, but obviously smtpd cannot provide more guarantees than the filesystem itself provides. -- Gilles Chehade freelance developer/sysadmin/consultant http://www.poolp.org