Collection of debates on O_DIRECT.

有空看看各種不同角色的討論，還是有點意思的。先從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來說實在不是什麼好差事，系統應該稍微智能一點，自己去選擇合適的參數。