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. > > Gilles > > -- > Gilles Chehade > freelance developer/sysadmin/consultant > > http://www.poolp.org
