> 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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
