: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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
