The 'sane' response would be to buy high-end power protection equipment
and use redundant drive configurations (RAID) and only worry about whether
the kernel writes out data consistently or not (and good journalling takes
care of many performance issues here).
Reliability of gigabytes per minute of data is not just a case of
demanding synchronous writes (which is silly in many cases). Power faults
can be protected against as can many cases of hardware failure.
Performance should not be sacrificed for the cases where someone has a
high case of failure potential (high being relative).
Greg Hudson wrote:
> (Of course, if
> you disk controller reorders write operations you'll lose no matter
> what. Unfortunately, you have to choose both your hardware and your
> software somewhat carefully if you really care about filsystem
> consistency.)
>
> Linux ext2fs has no write ordering whatsoever. If the system goes
> down uncleanly, you can get metadata pointing to bad data or data not
> pointed to by metadata. A recently created file might exist but
> contain blocks from an old copy of /etc/shadow instead of the data you
> wrote to it. It's really ugly. fsck cannot correct all of the
> possible problems which can arise, no matter how clever or thorough it
> is. People have tried to justify this state of affairs in lots of
> ways, but the only potentially correct and convincing justification
> is, "who cares?" Which is great unless you're one of the (admittedly,
> relatively few) people who does care.
>
> Note that write ordering is different from synchronous
> vs. asynchronous operations. Write ordering is about filesystem
> consistency, which is mostly irrelevant to qmail's operation because
> of the way qmail works. ext2fs is also a little odd with respect to
> synchronous operations (as discussed in my last piece of mail), but
> it's certainly possible to work around that.
