> Thus why all reasonably paranoid MTAs and other mail programs say "use
> chattr +S on ext2"---we need ordered metadata writes.
And then your IDE disk gets you anyway. Also if you write metadata first
then you risk delivering email to the wrong person instead.
These are tangential issues. Not everybody uses IDE disks. I'm not
asking for things that are impossible. Just because sometimes the
hardware screws you isn't a good reason for not trying to do the right
The application can avoid the wrong file problem by zeroing out data
before releasing it to the OS to reallocate.
> You want to help performance? Give us an fsync() that works on
> multiple file descriptors at once, or an async fsync() call. Don't
> make us fight the OS on getting data to disk.
And what pray does an asynchronous fsync do. It seems to be a nop to me.
An async fsync allows me to issue multiple fsyncs and then wait for
all of them to complete, hopefully in the same framework that I would
do async I/O (but that's an argument for another day).
Doing reliabile transactions on disk is a hard problem. That is why oracle
and friends have spent many man years of research on this kind of problem.
Current unix mailers do the smoke mirrors and prayer bit to reduce the
probability a little that is all, regardless of fs and os.
Isn't the point of the operating system to try to make it as easy as
possible to do these things correctly?
Otherwise you force anyone who wants to write a reliable application
(be it e-mail or not) to go to Oracle and one wonders why fsync() is
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/