看看各种不同角色的讨论，还是有点意思的。先从 Linus 的这个开始：O_DIRECT (Larry McVoy; Linus Torvalds) - Yarchive 注意，这个帖子有点长，而且时间跨度有点大。要有点耐心才能看完。

早些年开始学 DBMS 的人都知道为什么要用 O_DIRECT，事实上也有很多的系统就是这样做的。当初的文件系统其实很弱，很多方面反而是 DBMS 先搞出来的，二者在发展过程中不断互相借鉴，互相适配，但又远远没有达到配合默契的程度。在事务处理/日志恢复，缓冲区算法这些技术方面，DBMS 的理论和实践都要略胜一筹。为了在磁盘设备上做出比较高性能的数据库，早期的 DBMS 厂家费劲了心思，要求文件系统提供 O_DIRECT 这样的接口也是可以理解的。只不过闭源软件没有兴趣把接口定义得那么好，也不全面考虑 DBMS 之外的通用性。造成既成事实之后，也没有哪家文件系统有兴趣来扭转这种局面，更何况开源的文件系统又比较多，要让 DBMS 少做点额外的工作，靠文件系统就很难得到一致的性能表现。开源的 DBMS 中，PostgreSQL 是比较喜欢依靠文件系统的，可是遇到了一些麻烦：http://lwn.net/Articles/580542/。其中最典型的问题当属该文章链接的这个：http://www.postgresql.org/message-id/17515.1389715715@sss.pgh.pa.us。

O_DIRECT 是如此的混乱，除了上面的长篇大论之外，这里还有了个专门的讨论页面：Clarifying Direct IO’s Semantics - Ext4，而数据中也是参数成堆，令人头大不已。例如开源数据库 MySQL 引入了各种不同的 innodb_flush_method 参数取值：https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html。对着一大堆参数来调优，对于 DBA 来说实在不是什么好差事，系统应该稍微智能一点，自己去选择合适的参数。