Date: Tue, 6 Feb 2001 09:59:57 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Mike Silbersack <silby@silby.com> Cc: Rik van Riel <riel@conectiva.com.br>, 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: <200102061759.f16Hxv662437@earth.backplane.com> References: <Pine.BSF.4.31.0102061149180.14899-100000@achilles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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 That information is incorrect as well. BSD has no such semantics. A normal FFS mount will do synchronous metadata updates for certain cases, and will try to sync the directory in certain cases including some of the above mentioned cases, but this does *NOT* in any way guarentee directory or file consistency at the time of the link(), unlink(), etc... For a normal FFS mount, all it does is reduce the probability that something will break in a crash. Maybe they got confused with NFS. The NFS server code guarentees stable storage semantics for certain cases, and enforces it by fsync()ing. But even NFS does not guarentee stable storage for open() until you fsync(). NFS does typically fsync() on last-close(), but... And, I would say, that for any mailer creating and deleting files in a spool directory at a high rate, *ONLY* a filesystem with softupdates turned on or a journaling filesystem such as XFS or ReiserFS can be considered crash-surviveable. Synchronous meta-data updates will not save you (EXT2FS or FFS without softupdates). -Matt 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?200102061759.f16Hxv662437>