From owner-freebsd-questions@FreeBSD.ORG Mon Sep 24 13:51:40 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 419FC16A417 for ; Mon, 24 Sep 2007 13:51:40 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from mail.beenic.net (mail.beenic.net [83.246.72.40]) by mx1.freebsd.org (Postfix) with ESMTP id 032C113C455 for ; Mon, 24 Sep 2007 13:51:39 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from [192.168.1.37] (a89-182-71-41.net-htp.de [89.182.71.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.beenic.net (Postfix) with ESMTP id BED85A44529 for ; Mon, 24 Sep 2007 15:47:29 +0200 (CEST) From: "Heiko Wundram (Beenic)" Organization: Beenic Networks GmbH To: freebsd-questions@freebsd.org Date: Mon, 24 Sep 2007 15:51:35 +0200 User-Agent: KMail/1.9.7 References: <48ce8d530709211747s615bc16by5766441066f19237@mail.gmail.com> <20070924132409.GB14133@parts-unknown.org> In-Reply-To: <20070924132409.GB14133@parts-unknown.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709241551.35615.wundram@beenic.net> Subject: Re: migrate from postfix to qmail X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2007 13:51:40 -0000 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