Barriers do work as we have them, but as others have mentioned, it is
not a "free" win - fsync will actually move your data safely out to
persistent storage for a huge percentage of real users (including every
ATA/S-ATA and SAS drive I was able to test). The file systems I
monitored in production use without barriers were much less reliable.

The problem is that, as long as you're not under memory pressure, and
not pushing the filesystem heavily, ext3 didn't corrupt *that* often
without barriers. So people got away with it "most of the time" ---
just as applications replacing files by rewriting them in place using
truncate and w/o fsync would "usually" not lose data after a crash if
they were using ext3 with data=ordered mode. This caused people to
get lazy/sloppy.
So yes, barriers were something that were largely ignored for a long
time. After all, in a server environment with UPS's, without crappy
proprietary video drivers, Linux systems didn't crash that often
anyway. So you really needed a large base of systems and with the
ability to root cause failures such as what Ric had at EMC to see the
problem.

One thing to point out here is that there are a lot of "servers" in high
end data centers that do not have UPS backup. Those racks full of 1U and
2U boxes that are used to make "grids", "clouds" and so on often are
built with as much gear as you can stuff in a rack - no batteries or UPS
to be seen, so they are really quite similar to the normal desktop or
home systems that we normally run at home :-)

ric

Even now, the reason why ext3 doesn't have barriers enabled by default
(although we did make them the default for ext4) is because Andrew
doesn't believe Chris's replication case is likely to be true for most
users in practice, and he's concerned about the performance
degradation of barriers. He's basically depending on the fact that
"usually" you can get away without using barriers. Sigh....
- Ted
P.S. Of course, distributions should feel free to consider changing
the default on their kernels. SLES has already if memory serves
correctly. I don't know if RHEL has yet.