[EMAIL PROTECTED] wrote:
>
> On Thu, Feb 03, 2000 at 01:07:47PM -0600, [EMAIL PROTECTED] wrote:
> > Neither does vanilla FFS (which is apparently Dan's
> > benchmark for reliability). That's why the fsync()
> > call was invented. FFS/softupdates honors fsync
> > calls, FFS/async does not. That's the difference.
>
> I believe that ext2 honors fsync() as well (but not in 2.3 yet).
> Could someone who knows more confirm? The metadata is still
> asyncronous though so FFS with softupdates is probably better.
OK, to get things how they are:
1. Linux honors fsync() for data but NOT for metadata (unless you
fsync() the directory the file is in).
-> The fsync() call returns when the data is written to disk but
not the metadata (happens every 30s). This leads qmail-queue
to believe everything is written completly onto safe storage
and returns message queued. If you loose power the next secs
you loose the file also. This does not mean your FS is corrupted.
== not reliable for DJB
2. *BSD FFS (with and without softupdates) honors fsync() for data
AND metadata in any case.
-> The fsync() call returns when the data and metadata is written
to the disk.
== reliable for DJB
This discussion is not only about lost filesystems but lost files.
> Also note the journalling version ResierFS only writes metadata
> to the journal. ext3 journals both data and metadata. You
> want both for qmail.
Well, that doesn't matter at all as long the fsync() system call
semantics are honored by the operating system and filesystem.
--
Andre
