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

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

• 文件的字節(jié)數(shù)
• 文件的權(quán)限
• 文件的時間戳
• 鏈接的數(shù)量，即有多少文件指向該inode
• 指向數(shù)據(jù)塊的鏈接
• etc

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

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中的元數(shù)據(jù)是保存在inode cache中，inode的保存文件的數(shù)據(jù)是保存在操作系統(tǒng)緩存中（若未開啟O_DIRECT標識）。讀者可以觀察下圖Linux文件系統(tǒng)的實現(xiàn)方式： ? fsync操作會同步上圖中的Inode cache，Buffer cache（也就是操作系統(tǒng)緩存），Directory cache。 因此這就是為什么InnoDB存儲引擎即使在文件打開時加上O_DIRECT標識，刷新臟頁依然需要fsync操作。這是因為O_DIRECT標識只是忽 略了圖中Buffe cache。刷新文件的另一個函數(shù)fdatasync，其僅刷新buffer cache的內(nèi)容到磁盤，因此比fsync有更好的性能，但是存在數(shù)據(jù)丟失的風險。 若用戶想通過O_DIRECT寫入文件，但避免可能存在的潛在風險時，可以再加上O_SYNC標識，此時寫入實際變?yōu)榱艘粋€同步寫（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.

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

轉(zhuǎn)載于:https://www.cnblogs.com/zhoujinyi/p/3179279.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。