[dm-devel] Barriers still not passing on simple dm devices...

[Mikulas Patocka]

> 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....

What is the performance degradation of barriers?

If the disk doesn't have write cache, performance of barrier-filesystem 
should be equal or better than performance of the same filesystem not 
using barriers. If barriers degrade performance, there is something 
seriously broken, either in the filesystem (XFS...) or in the block layer.

If the disk has write cache and you disable barriers, you might get some 
performance improvement. But you are getting this performance improvement 
from the fact that the disk illegaly reorders writes that should be 
ordered. And you are going to damage your data on power failure.

--- definitely, very few admins want this "high-performance & damage" 
setup (maybe for /tmp or /var/log?) --- such condition sould be only 
enabled with admin fully knowning what's going on. And where should the 
admin get the knowledge?

In hdparm manpage, there is just:
-W     Get/set the IDE/SATA drive's write-caching feature.

> 						- 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.

RHEL doesn't enable write cache by default. And doesn't use barriers (it 
uses lvm2/device mapper and they won't get through).

Mikulas