本文來自：http://insidemysql.blog.163.com/blog/static/2028340422013671186977/ 最近和文件系統內核開發人員做技術交流，對O_DIRECT選項有了新的認識。 在 InnoDB存儲引擎的配置中參數innodb_flush_method通常設置為O_DIRECT，這也是官方文檔所推薦的設置值。DBA或開發人員 知道該參數是文件打開的一個標識，啟用后文件的寫入將繞過操作系統緩存，直接寫文件。其在InnoDB存儲引擎中的表現為對于寫入到數據表空間將繞過操作 系統緩存。這樣設置通常不會有更好的性能，但是數據庫已經有自己的緩存系統，這樣的設置可以確定數據庫系統對于內存的使用。下面是man手冊中對于 O_DIRECT選項的說明：

Try to minimize cache effects of the I/O to andfromthis file.In general this will degrade performance, but it is useful in special situations, such aswhen applications do their own caching.

然而在源碼內，細心的讀者可能會產生一些困惑，因為不管參數innodb_flush_method的設置為何值，在刷新臟頁時都會調用fsync操作，具體見函數buf_flush_buffered_writes。那么，當用戶已經打開文件操作的O_DIRECT標識，為什么還需要進行一次fsync操作確保文件的寫入呢？ 最早發現這個問題的是Facebook的MySQL團隊負責人Mark Calleghan。其在2009年時在MySQL數據庫的官方論壇中提交Bug #45892，當年看到此Bug的回復時還是有些疑惑，因為其答復的諸如xfs這類文件系統，有些元數據還需要通過fsync進行刷新。公司同事花花也有問過我同樣的問題，不知道是否在做云硬盤時遇到了類似問題。 最近和文件系統內核開發人員做交流，其對ext4的文件系統做了簡單的介紹，自己對文件系統有了重新認識，對之前Bug的回復也有了更為清楚的理解。在有些文件系統中，例如ext4、xfs，文件（包括目錄，在Linux中所有對象都是文件）都有一個inode與之對應，其保存有兩部分的內容，元數據和文件的存儲數據。根據wiki的介紹，元數據包含的內容有：

• 文件的字節數
• 文件的權限
• 文件的時間戳
• 鏈接的數量，即有多少文件指向該inode
• 指向數據塊的鏈接
• etc

可 以發現元數據及其重要的，不僅僅是文件最后修改時間、權限等信息，它還包含有指向存儲塊的信息。若在數據增長時，元數據沒有及時更新，那么同樣可能會導致 數據丟失的情況。雖然此時，數據可能在磁盤上，但文件不知道那些塊也是其組成部門。可以看到，這也是MySQL官網對上述Bug中的回復：

For example,if a file grows while O_DIRECT is enabled it will still write to the new part of the file, however since the metadata doesn't reflect the new size of the file the tail portion can be lost in the event of a crash.

inode中的元數據是保存在inode cache中，inode的保存文件的數據是保存在操作系統緩存中（若未開啟O_DIRECT標識）。讀者可以觀察下圖Linux文件系統的實現方式： ? fsync操作會同步上圖中的Inode cache，Buffer cache（也就是操作系統緩存），Directory cache。 因此這就是為什么InnoDB存儲引擎即使在文件打開時加上O_DIRECT標識，刷新臟頁依然需要fsync操作。這是因為O_DIRECT標識只是忽 略了圖中Buffe cache。刷新文件的另一個函數fdatasync，其僅刷新buffer cache的內容到磁盤，因此比fsync有更好的性能，但是存在數據丟失的風險。 若用戶想通過O_DIRECT寫入文件，但避免可能存在的潛在風險時，可以再加上O_SYNC標識，此時寫入實際變為了一個同步寫（synchronous I/O）操作，因此不再需要額外的fsync操作。見man手冊中的說明：

The O_DIRECT flag on its own makes an effort to transfer data synchronously, but does not give the guarantees of the O_SYNC flag that data and necessary metadata are transferred.To guarantee synchronous I/O, O_SYNC must be used in addition to O_DIRECT.

未完待續...... ? MySQL5.6中增加了一個選項：O_DIRECT_NO_FSYNC

轉載于:https://www.cnblogs.com/zhoujinyi/p/3179279.html

總結

以上是生活随笔為你收集整理的InnoDB O_DIRECT选项漫谈（一）【转】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。