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
