您好,登錄后才能下訂單哦!
在很多IO場景中,我們經常需要確保數據已經安全的寫到磁盤上,以便在系統宕機重啟之后還能讀到這些數據。但是我們都知道,
linux系統
的IO路徑還是很復雜的,分為很多層,每一層都可能會有buffer來加速IO讀寫。同時,用戶態的應用程序和庫函數也可能擁有自己的buffer,這又給IO路徑增加了一些復雜性。可見,要想保證數據安全的寫到磁盤上,并不是簡單調一個write/fwrite就可以搞定的。
那么要怎么做呢?很多人會想到很多辦法,比如:fflush()、fsync()、fdatasync()、sync()、open()使用O_DIRECT或O_SYNC標志等。嗯,這些手段(或者某些組合)的確可以保證數據安全的持久化,那么它們之間有什么區別呢?fflush()和fsync()有啥區別?O_DIRECT是啥意思,它可以保證數據安全的持久化嗎?O_DIRECT和O_SYNC區別什么?O_SYNC和fsync()呢?fsync能完成msync的功能嗎?本文將試圖理解、解釋這些概念的作用和區別。
所謂一圖勝千言,為了解析清楚這些概念的區別,我特意畫了一張圖,仔細看,應該可以清晰的看出它們的作用和區別。
這里重點說一下O_DIRECT和O_SYNC,首先要明確的是,O_DIRECT只是說數據不會經過page cache(一般用在用戶態自己管理buffer)而是直接提交給塊設備層,但是不會同步等待數據安全寫入磁盤之后才返回(比如數據可能還在塊層排隊或者在磁盤自己的cache中)。而O_SYNC標志,雖然數據還是會寫page cache,但是此時會采用write through的策略,并同步等待數據安全寫入磁盤后才會返回。因此如果同時使用O_DIRECT和O_SYNC,則表示數據不會經過page cache并同步等待數據安全寫入磁盤才返回,當然這樣IO的性能會非常低下。
由于O_DIRECT會bypass page cache,因此如果有另一個進程使用普通的方式讀文件,有可能會出現數據不一致的現象,這個也需要注意。
為了做一下輔助說明,此處我貼一下我探討過程中看過的一些資料。首先是引用open系統調用:
http://man7.org/linux/man-pages/man2/open.2.html
相關參數的說明:
以及innodb相關的文檔:
https://lwn.net/Articles/457667/
fsync和fdatasync的區別:
http://man7.org/linux/man-pages/man2/fsync.2.html
msync:
http://man7.org/linux/man-pages/man2/msync.2.html
其實還有一種IO模式,就是DAX(Direct Access ),是不是看上去和O_DIRECT很像。這種模式需要filesystem和block driver都支持才可以,一般主要用在non volatile memory上,本質上也是繞過page cache直接操作設備。DAX本文先不做深入探討,后面我會自己寫一個支持DAX模式的ramdisk塊設備驅動,然后格式化為ext4文件系統并-o dax模式掛載,再來詳細研究DAX的IO路徑。
最后附上Linux在常見場景下的io路徑跟蹤:
https://my.oschina.net/fileoptions/blog/3061822
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。