Date: Tue, 06 Feb 2001 20:32:07 +0100 From: Andre Oppermann <oppermann@monzoon.net> To: Matt Dillon <dillon@earth.backplane.com> Cc: Mike Silbersack <silby@silby.com>, 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: <3A805137.230E0A0D@monzoon.net> References: <Pine.BSF.4.31.0102061149180.14899-100000@achilles.silby.com> <200102061759.f16Hxv662437@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon wrote: > > :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. This information is in fact correct. Have a look at the FreeBSD link(2) man page: LINK(2) FreeBSD System Calls Manual LINK(2) NAME link - make a hard file link SYNOPSIS #include <unistd.h> int link(const char *name1, const char *name2) DESCRIPTION The link() function call atomically creates the specified directory entry ^^^^^^^^^^ (hard link) name2 with the attributes of the underlying object pointed at by name1. If the link is successful: the link count of the underlying ob- ject is incremented; name1 and name2 share equal access and rights to the underlying object. If name1 is removed, the file name2 is not deleted and the link count of the underlying object is decremented. Name1 must exist for the hard link to succeed and both name1 and name2 must be in the same file system. name1 may not be a directory. > 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). Sync meta-data updates safes me. Qmail depends on the atomicallity of this call. -- 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?3A805137.230E0A0D>