APUE 關於O SYNC等的區別

陶方在《innodb_flush_method帶來的效能影響》中從實驗角度比較了fdatasync，o_dsync和o_direct在效能上的差異。本文將試圖從linux/unix"檔案i/o"（unbuffered i/o）的角度來解釋innodb_flush_method是如何影響mysql的i/o。【附錄1】

innodb_flush_log_at_trx_commit引數確定日誌檔案何時write、flush。innodb_flush_method則確定日誌及資料檔案如何write、flush。在linux下，innodb_flush_method可以取如下值：fdatasync, o_dsync, o_direct，那這三個值分別是如何影響檔案寫入的？首先我們需要先來了解linux的檔案i/o是如何工作的。

先來看看linux/unix檔案i/o的乙個典型例子：（linux 2.6.24測試，gcc編譯）

/**
a test about syscall of file i/o
author:supu@taobaodba
[email protected] 
*/#include "stdlib.h" /* for exit */
#include "unistd.h" /* for write fdatasync*/
#include "fcntl.h" /* for open */
int main(void)
char buff="abcdef";
if(write(fd,buff,6)!= 6)
if(fdatasync(fd)==-1)
exit(0);
}

程式描述了一般的檔案i/o操作的三個過程open、write、fdatasync，分別是開啟檔案、寫檔案、flush操作（將檔案快取刷到磁碟上）。

一、open階段

o_wronly表示我們以"寫"的方式開啟，告訴核心我們需要向檔案中寫入資料；

o_dsync告訴核心，當向檔案寫入資料的時候，只有當資料寫到了磁碟時，寫入操作才算完成（write才返回成功）。和o_dsync同類的檔案標誌，還有o_sync,o_rsync，o_direct。

二、write階段

write(fd,buf,6)

在使用open開啟檔案獲得檔案描述符之後，我們就可以呼叫write函式來寫入資料了，write會根據前面的open引數不同，而表現不同。

三、flush階段

fdatasync(fd) == -1

write操作後，我們還呼叫了fdatasync來確保檔案資料flush到了disk上。fdatasync返回成功後，那麼可以認為資料已經寫到了磁碟上。像這樣的flush的函式還有fsync、sync。

fsync和fdatasync的區別等同於o_sync和o_dsync的區別。

sync函式表示將檔案在os cache中的資料排入寫佇列，並不確認是否真的寫磁碟了，所以sync並不可以靠。

忽略檔案開啟的過程，通常我們會說「寫檔案」有兩個階段，乙個是呼叫write我們稱為寫資料階段（其實是受open的引數影響），呼叫fsync（或者fdatasync）我們稱為flush階段。

回到mysql，引數innodb_flush_method(linux)可以設定為：fdatasync、o_dsync、o_direct。我們看看這個三個引數是如何影響程式mysql對日誌和資料檔案的操作：

open log

flush log

open datafile

flush data

fdatasync

fsync()

o_dsync

o_sync

fsync()

o_direct

fsync()o_direct

fsync()

fdatasync被認為是安全的，因為在mysql總會呼叫fsync來flush資料。使用o_dsync是有些風險的，有些os會忽略該引數o_sync。

我們看到o_direct和fdatasync和很類似，但是它會使用o_direct來開啟資料檔案。有資料表明，如果是大量隨機寫入操作，o_direct會提公升效率。但是順序寫入和讀取效率都會降低。所以使用o_direct需要謹慎。

參考文章：

unix環境高階程式設計（第二版）

系統呼叫：

可以簡單的理解為：「系統呼叫「是在核心之上的一層封裝。由核心直接提供介面，「系統呼叫」需要陷入核心執行（核心態）。其中fdatasync就是乙個系統呼叫，該系統呼叫可以通知os立刻將os cache中的資料flush到磁碟檔案中。

【附錄2】這時候核心會為該該程序開啟的檔案分配乙個檔案描述符，並將該檔案描述符返回給該程序。在核心的檔案表中新建乙個檔案項，標記檔案狀態、檔案當前偏移、以及i節點（v節點）的位置，核心還會開啟該檔案的i節點（這裡記錄檔案的操作的函式指標，例如讀操作、寫操作）。

【附錄3】o_rsync我的理解是，對於同乙個檔案描述符可以保證讀資料安全。同乙個檔案描述符包括dup和fcntl函式dup的檔案描述符，即共用同乙個檔案表項。o_rsync不是我們今天關注的，暫時忽略

未解問題:

o_direct在哪些os(或者fs)上能夠正常工作？

o_sync在哪寫os上不能正常工作呢？

核心的read、write是fs級別的還是核心(kernel)級別？

文章innodb_flush_method帶來的效能影響中o_dsync、和fdatasync效率差很多，這是為什麼？

APUE 關於O SYNC等的區別

Null,DBNULL等的區別？

「等燈等燈等燈」，和的區別

關於jvm tomcat jboss等的引數配置

APUE 關於O SYNC等的區別

Null,DBNULL等的區別？

「等燈 等燈等燈」， 和 的區別

關於jvm tomcat jboss等的引數配置

相關推薦

「等燈等燈等燈」，和的區別