Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Feb 2001 11:52:10 -0600 (CST)
From:      Mike Silbersack <silby@silby.com>
To:        Rik van Riel <riel@conectiva.com.br>
Cc:        Poul-Henning Kamp <phk@critter.freebsd.dk>, Charles Randall <crandall@matchlogic.com>, 'Matt Dillon' <dillon@earth.backplane.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:  <Pine.BSF.4.31.0102061149180.14899-100000@achilles.silby.com>
In-Reply-To: <Pine.LNX.4.21.0102061538290.1535-100000@duckman.distro.conectiva>

next in thread | previous in thread | raw e-mail | index | archive | help

On Tue, 6 Feb 2001, Rik van Riel wrote:

> The system call used to guarantee this is fsync (and friends?);
> if qmail doesn't use it but makes assumptions that aren't true
> on any decent OS out there ...
>
> regards,
>
> Rik

Well, the various qmail programs do seem to fsync (though I'm not sure if
it's in the right places.)  In any case, this link seems to throw some
light on the situation:

ftp://elektroni.ee.tut.fi/pub/qmail_linux_metadata_message

Now, I have no clue if this is correct or not, but the core of the
explanation given on that page seems to be:

---

So what is this all about? qmail relies on the BSD semantics of immediate
update of directories on the disk when link(), unlink(), open() and
rename() calls are used. But Linux writes them to the disk asynchronously.
My library loaded before libc changes those calls to do the corresponding
directory writes too. Then qmail should be reliable against power outages
also in Linux.

---

So, does anyone know if that is a correct assertion to make, and if
softupdates does indeed break it?

Mike "Silby" Silbersack



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?Pine.BSF.4.31.0102061149180.14899-100000>