Date: Tue, 6 Feb 2001 11:43:51 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Andre Oppermann <oppermann@monzoon.net> Cc: Rik van Riel <riel@conectiva.com.br>, Mike Silbersack <silby@silby.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Charles Randall <crandall@matchlogic.com>, Dan Phoenix <dphoenix@bravenet.com>, Alfred Perlstein <bright@wintelcom.net>, Jos Backus <josb@cncdsl.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: soft updates and qmail (RE: qmail IO problems) Message-ID: <200102061943.f16Jhp365113@earth.backplane.com> References: <Pine.LNX.4.21.0102061555550.1535-100000@duckman.distro.conectiva> <3A805035.C71AAD5E@monzoon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:> Pre-softupdate BSD semantics, apparently. Doesn't sound like
:> the smartest thing to do when you want a reliable MTA...
:
:This description is not entirely right.
:
:Qmail depends on ordered-metadata updates (Terry! :-). That means
:if you issue a link() to the new place and a unlink() in the old
:place it should guarantee that the link() happens *BEFORE* the
:unlink(). At least standard FFS/UFS does this. Linux ext2 might
:do the the unlink() before the link() and a crash in that moment
:will loose the file completely. It is all about the ordering
:guarantee.
No filesystem can guarentee ordered metadata upates. Well, that
isn't quite true... a journaled filesystem can, but it is usually
undesireable to have a global ordering guarentee for a filesystem
because you can end up in a situation where you have lots of processes
banging on unrelated areas of the filesystem in parallel, and an
fsync() of one descriptor would have to wait for the entire filesystem
to reach a synchronization point to guarentee metadata update ordering.
This creates a serious scaleability issue within a filesystem!
Standard FFS/UFS does *NOT* guarentee ordered metadata updates. It
uses synchronous directory updates for certain operations, but these
only provide guarentees when operating on lightly loaded directories.
Heavily loaded directories can still (and probably will) wind up in a
corrupted state if the system crashes at the wrong time. Dealing with
the issue of multiple processes banging on a single directory all
at the same time, doing simultanious file creates and deletions, is a
very complex problem to solve, and FFS/UFS does not solve it. Softupdates
solves the problem, but even softupdates still doesn't try to guarentee
metadata update ordering because it is extremely difficult to do it and
still have reasonable filesystem performance.
So the simple answer here is that if QMail is relying on ordered metadata
updates, it is relying on something that virtually nobody supports
with any real level of confidence. If you want to achieve a database's
transactional qualities, you need to write meta-data operations to a log
file, cluster the writes within a filesystem block properly, and fsync()
the log file so you can rerun it after a crash.
(I will mention here that, of course, sendmail and postfix are no better
in this regard. This is not a detriment to QMail itself verses other
mailers. Since QMail fsync()'s reasonably, it will be just as reliable
as other existing MTAs).
-Matt
:> If djb could be considered to take things like reliability
:> and the SMTP specification into account, and not just
:> security, then qmail would have the potential to be a pretty
:> decent mailer.
:
:He did and qmail is one of the best and most reliable mailers on
:the Internet.
:
:> As it is, I can only recommend people to go with something
:> like postfix, Exim or zmailer ...
:
:Have a look at the qmail source and the facts before you spill
:out such a *bullshit*!
:
:--
:Andre
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102061943.f16Jhp365113>