Date: Mon, 24 Sep 2007 15:51:35 +0200 From: "Heiko Wundram (Beenic)" <wundram@beenic.net> To: freebsd-questions@freebsd.org Subject: Re: migrate from postfix to qmail Message-ID: <200709241551.35615.wundram@beenic.net> In-Reply-To: <20070924132409.GB14133@parts-unknown.org> References: <48ce8d530709211747s615bc16by5766441066f19237@mail.gmail.com> <fd8cjp$2mm5$8@nermal.rz1.convenimus.net> <20070924132409.GB14133@parts-unknown.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Am Montag 24 September 2007 15:24:09 schrieb David Benfell: > And not that this is the first file system issue I've heard about with > qmail, but what is an MTA doing that should be file system dependent in any > way? I *am* a happy qmail user, but this is something I just don't get. It is filesystem dependent when a write to a filesystem actually becomes permanent (even when O_(D)SYNC is specified in the open syscall, that just makes sure the file data is committed immediately to disk), in the sense that if you switch off the power without syncing, that after filesystem reconstruction on reboot the file is still there, with its contents. (think about delayed metadata-updates on FreeBSD UFS2, for example, ReiserFS has a similar kind of behaviour wrt. updating its B-tree) Only after this "true" commit has happened is the MTA actually able to give a proper 200 in reply to finishing the SMTP DATA-command, because it can be sure that the mail won't be lost under all "normal" circumstances (besides having the HD hardware fail, which generally isn't catered for by the MTA). Qmail simply doesn't check properly (in the case of ReiserFS) whether the file has been truly committed before it gives out the 200 reply, so basically, if you deploy ReiserFS (which is known to cache its B-tree aggressively) and have a power-outage while Qmail is writing the queue file to disk, you're at odds that the mail is lost simply because Qmail has already given out the 200 reply to the remote server, even though the file information hasn't been committed to the ReiserFS B-tree (or the journal) yet, so that the file won't be recreated during journal-replay. -- Heiko Wundram Product & Application Development
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200709241551.35615.wundram>