InnoDB 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
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选项漫谈(一)【转】的全部內容,希望文章能夠幫你解決所遇到的問題。
 
                            
                        - 上一篇: 解决 rake aborted!
- 下一篇: Android中的主题Theme
