對于提供事務支持的數據庫，在事務提交時，都要確保事務日志（包含該事務所有的修改操作以及一個提交記錄）完全寫到硬盤上，才認定事務提交成功并返回給應用層。

一個簡單的問題：在*nix操作系統上，怎樣保證對文件的更新內容成功持久化到硬盤？

?

1. ?write不夠，需要fsync

一般情況下，對硬盤（或者其他持久存儲設備）文件的write操作，更新的只是內存中的頁緩存（page cache），而臟頁面不會立即更新到硬盤中，而是由操作系統統一調度，如由專門的flusher內核線程在滿足一定條件時（如一定時間間隔、內存中的臟頁達到一定比例）內將臟頁面同步到硬盤上（放入設備的IO請求隊列）。 因為write調用不會等到硬盤IO完成之后才返回，因此如果OS在write調用之后、硬盤同步之前崩潰，則數據可能丟失。雖然這樣的時間窗口很小，但是對于需要保證事務的持久化（durability）和一致性（consistency）的數據庫程序來說，write()所提供的“松散的異步語義”是不夠的，通常需要OS提供的同步IO（synchronized-IO）原語來保證： 1 #include <unistd.h> 2 int fsync(int fd); fsync的功能是確保文件fd所有已修改的內容已經正確同步到硬盤上，該調用會阻塞等待直到設備報告IO完成。 ? ? PS：如果采用內存映射文件的方式進行文件IO（使用mmap，將文件的page cache直接映射到進程的地址空間，通過寫內存的方式修改文件），也有類似的系統調用來確保修改的內容完全同步到硬盤之上： 1 #incude <sys/mman.h>
2 int msync(void *addr, size_t length, int flags)

msync需要指定同步的地址區間，如此細粒度的控制似乎比fsync更加高效（因為應用程序通常知道自己的臟頁位置），但實際上（Linux）kernel中有著十分高效的數據結構，能夠很快地找出文件的臟頁，使得fsync只會同步文件的修改內容。

?

2. fsync的性能問題，與fdatasync

除了同步文件的修改內容（臟頁），fsync還會同步文件的描述信息（metadata，包括size、訪問時間st_atime & st_mtime等等），因為文件的數據和metadata通常存在硬盤的不同地方，因此fsync至少需要兩次IO寫操作，fsync的man page這樣說：

"Unfortunately?fsync()?will always initialize two write operations : one for the newly written data and another one in order to update the modification time stored in the inode. If the modification time is not a part of the transaction concept?fdatasync()?can be used to avoid unnecessary inode disk write operations."

多余的一次IO操作，有多么昂貴呢？根據Wikipedia的數據，當前硬盤驅動的平均尋道時間（Average seek time）大約是3~15ms，7200RPM硬盤的平均旋轉延遲（Average rotational latency）大約為4ms，因此一次IO操作的耗時大約為10ms左右。這個數字意味著什么？下文還會提到。

?

Posix同樣定義了fdatasync，放寬了同步的語義以提高性能：

1 #include <unistd.h> 2 int fdatasync(int fd); fdatasync的功能與fsync類似，但是僅僅在必要的情況下才會同步metadata，因此可以減少一次IO寫操作。那么，什么是“必要的情況”呢？根據man page中的解釋： "fdatasync does not flush modified metadata unless that metadata is needed in order to allow a subsequent data retrieval to be corretly handled." 舉例來說，文件的尺寸（st_size）如果變化，是需要立即同步的，否則OS一旦崩潰，即使文件的數據部分已同步，由于metadata沒有同步，依然讀不到修改的內容。而最后訪問時間(atime)/修改時間(mtime)是不需要每次都同步的，只要應用程序對這兩個時間戳沒有苛刻的要求，基本無傷大雅。 ? ? PS：open時的參數O_SYNC/O_DSYNC有著和fsync/fdatasync類似的語義：使每次write都會阻塞等待硬盤IO完成。（實際上，Linux對O_SYNC/O_DSYNC做了相同處理，沒有滿足Posix的要求，而是都實現了fdatasync的語義）相對于fsync/fdatasync，這樣的設置不夠靈活，應該很少使用。 ? ?

3. 使用fdatasync優化日志同步

文章開頭時已提到，為了滿足事務要求，數據庫的日志文件是常常需要同步IO的。由于需要同步等待硬盤IO完成，所以事務的提交操作常常十分耗時，成為性能的瓶頸。 在Berkeley DB下，如果開啟了AUTO_COMMIT（所有獨立的寫操作自動具有事務語義）并使用默認的同步級別（日志完全同步到硬盤才返回），寫一條記錄的耗時大約為5~10ms級別，基本和一次IO操作（10ms）的耗時相同。 ?我們已經知道，在同步上fsync是低效的。但是如果需要使用fdatasync減少對metadata的更新，則需要確保文件的尺寸在write前后沒有發生變化。日志文件天生是追加型（append-only）的，總是在不斷增大，似乎很難利用好fdatasync。 ? 且看Berkeley DB是怎樣處理日志文件的： 1.每個log文件固定為10MB大小，從1開始編號，名稱格式為“log.%010d" 2.每次log文件創建時，先寫文件的最后1個page，將log文件擴展為10MB大小 3.向log文件中追加記錄時，由于文件的尺寸不發生變化，使用fdatasync可以大大優化寫log的效率 4.如果一個log文件寫滿了，則新建一個log文件，也只有一次同步metadata的開銷

?

?

參考資料：

1. linux man pages for fsync/msync/open 2. 《Unix環境高級編程》 3. Berkeley DB Source Code

?

轉載于:https://www.cnblogs.com/promise6522/archive/2012/05/27/2520028.html

總結

以上是生活随笔為你收集整理的小议同步IO ：fsync与fdatasync的全部內容，希望文章能夠幫你解決所遇到的問題。

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