本文针对RHEL 6.
文件系统作为大部分数据库的存储载体（ORACLE raw等其他由应用程序接管的I/O操作除外），一致性非常重要。
write barriers 是一种内核机制，用来确保文件系统metadata被正确并有序的写入持久化存储介质，不管底层存储是否有易失CACHE，不管电源是否突然关闭，都可以被确保。
一个开启了write barriers的文件系统，使用fsync()方法写入的数据将被确保被正确并有序的写入持久化存储介质。不管底层存储是否有易失CACHE，不管电源是否突然关闭，都可以被确保。
当然开启write barriers将导致性能下降，特别在频繁的fsync()调用，或频繁的创建或删除大量小文件时。
文件系统非常关心的一个操作是metadata的安全更新.对于一个日志型的文件系统，metadata的更新被绑定到一个transaction中，写入到持久化的底层存储，操作顺序如下：
- First, the file system sends the body of the transaction to the storage device.
- Then, the file system sends a commit block.
- If the transaction and its corresponding commit block are written to disk, the file system assumes that the transaction will survive any power failure.
现在的硬盘，RAID卡，磁盘柜都带有自身的CACHE，还有操作系统本身的CACHE，如果电源丢失导致这些CACHE丢失，都可能引发文件系统不一致。打个比方，commit block写入了，但是对应的transaction body只写入了部分或完全没有写入，那么在电源恢复的时候，As a result, the journal may replay these uninitialized transaction blocks into the file system during post-power-loss recovery; this will cause data inconsistency and corruption.
write barriers是如何来确保数据被正确写入到持久化存储了呢？
After the transaction is written, the storage cache is flushed, the commit block is written, and the cache is flushed again. This ensures that:
- The disk contains all the data.
- No re-ordering has occurred.
With barriers enabled, an fsync() call will also issue a storage cache flush. This guarantees that file data is persistent on disk even if power loss occurs shortly after fsync() returns.
从write barriers的运行机制来看，flush cache的操作变得非常频繁。因此开启write barriers的同时开启设备的WRITE CACHE，将造成写性能下降。
对于不带写CACHE的存储设备，或带掉电保护的CACHE，或者高端存储上的CACHE。可以考虑关闭write barriers来获得好的性能，同时不牺牲数据的一致性。
关闭write barriers只需要在挂载设备时添加参数 -o nobarrier 。
关闭了write barriers之后，还需要确保文件系统的一致性，可以通过关闭CACHE，使用可靠的高端存储来实现，对于NFS文件系统，客户端不需要打开write barriers，服务端需要打开write barriers。\
关闭CACHE的方法:
普通的本地硬盘hdparm -W0 /device/
对于有阵列卡的硬盘,MegaCli64 -LDGetProp -DskCache -LAll -aALLMegaCli64 -LDSetProp -DisDskCache -Lall -aALL