linux的同步IO操作函數: sync、fsync與fdatasync-聊聊 Linux IO

VFS（Virtual File System）的存在使得Linux可以兼容不同的文件系統，例如ext3、ext4、xfs、ntfs等等，其不僅具有為所有的文件系統實現一個通用的外接口的作用，還具有另一個與系統性能相關的重要作用——緩存。VFS中引入了高速磁盤緩存的機制，這屬於一種軟件機制，允許內核將原本存在磁盤上的某些信息保存在RAM中，以便對這些數據的進一步訪問能快速進行，而不必慢速訪問磁盤本身。高速磁盤緩存可大致分為以下三種：

目錄項高速緩存——主要存放的是描述文件系統路徑名的目錄項對象
索引節點高速緩存——主要存放的是描述磁盤索引節點的索引節點對象
頁高速緩存——主要存放的是完整的數據頁對象，每個頁所包含的數據一定屬於某個文件，同時，所有的文件讀寫操作都依賴於頁高速緩存。其是Linux內核所使用的主要磁盤高速緩存。

正是由於緩存的引入，所以VFS文件系統采用了文件數據延遲寫的技術，因此，如果在調用系統接口寫入數據時沒有使用同步寫模式，那么大多數據將會先保存在緩存中，待等到滿足某些條件時才將數據刷入磁盤里。

內核是如何將數據刷入磁盤的呢？

何時把臟頁寫入磁盤

內核不斷用包含塊設備數據的頁填充頁高速緩存。只要進程修改了數據，相應的頁就被標記為臟頁，即把它的PG_dirty標志位置。

Unix系統允許把臟緩沖區寫入塊設備的操作延遲執行，因為這種策略可以顯著地提高系統的性能。對高速緩存中的頁的幾次寫操作可能只需對相應的磁盤塊進行一次緩慢的物理更新就可以滿足。此外，寫操作沒有讀操作那么緊迫，因為進程通常是不會因為延遲寫而掛起，而大部分情況都因為延遲讀而掛起。

一個臟頁可能直到最后一刻（即直到系統關閉時）都一直逗留在主存中。然而，從延遲寫策略的局限性來看，它有兩個主要的缺點：

一、如果發生了硬件錯誤或者電源掉電的情況，那么就無法再獲得RAM的內容，因此，從系統啟動以來對文件進行的很多修改就丟失了。

二、頁高速緩存的大小（由此存放它所需的RAM的大小）就可要很大——至少要與所訪問塊設備的大小不同。

因此，在下列條件下把臟頁刷新（寫入）到磁盤：

頁高速緩存變得太滿，但還需要更多的頁，或者臟頁的數量已經太多。
自從頁變成臟頁以來已過去太長時間。
進程請求對塊設備或者特定文件任何待定的變化都進行刷新。通過調用sync()、fsync()或者fdatasync()系統調用來實現。

緩沖區頁的引入是問題更加復雜。與每個緩沖區頁相關的緩沖區首部使內核能夠了解每個獨立塊緩沖區的狀態。如果至少有一個緩沖區首部的PG_Dirty標志被置位，就應該設置相應緩沖區頁的PG_dirty標志。當內核選擇要刷新的緩沖區時，它掃描相應的緩沖區首部，並只把臟塊的內容有效的寫到磁盤。一旦內核把緩沖區的所有臟頁刷新到磁盤，就把頁的PG_dirty標志清0。

誰來把臟頁寫入磁盤

由pdflush內核線程負責。早期版本的Linux使用bdfllush內核線程系統地掃描頁高速緩存以搜索要刷新的臟頁，並且使用另一個內核線程kupdate來保證所有的頁不會“臟”太長時間。Linux 2.6用一組通用內核線程pdflush替代上述兩個線程。當系統沒有要刷新的臟頁時，pdflush線程會自動處於睡眠狀態，最后由pdflush_operation()函數來喚醒。

在下面幾種情況下，系統會喚醒pdflush回寫臟頁：

1 、定時方式：
定時機制定時喚醒pdflush內核線程，周期為/proc/sys/vm/dirty_writeback_centisecs ，單位
是(1/100)秒，每次周期性喚醒的pdflush線程並不是回寫所有的臟頁，而是只回寫變臟時間超過
/proc/sys/vm/dirty_expire_centisecs（單位也是1/100秒）。
注意：變臟的時間是以文件的inode節點變臟的時間為基准的，也就是說如果某個inode節點是10秒前變臟的，
pdflush就認為這個inode對應的所有臟頁的變臟時間都是10秒前，即使可能部分頁面真正變臟的時間不到10秒，
細節可以查看內核函數wb_kupdate()。

2、內存不足的時候：
    這時並不將所有的dirty頁寫到磁盤，而是每次寫大概1024個頁面，直到空閑頁面滿足需求為止。

3 、寫操作時發現臟頁超過一定比例：
    當臟頁占系統內存的比例超過/proc/sys/vm/dirty_background_ratio 的時候，write系統調用會喚醒
pdflush回寫dirty page,直到臟頁比例低於/proc/sys/vm/dirty_background_ratio，但write系統調
用不會被阻塞，立即返回。當臟頁占系統內存的比例超過/proc/sys/vm/dirty_ratio的時候， write系
統調用會被被阻塞，主動回寫dirty page，直到臟頁比例低於/proc/sys/vm/dirty_ratio，這一點在
2.4內核中是沒有的。

4 、用戶調用sync系統調用：
    這是系統會喚醒pdflush直到所有的臟頁都已經寫到磁盤為止。

linux系統在向存儲設備上寫數據的時候，其實，數據沒有被立即寫入到物理設備上，而一般處理過程是：

調用fwrite()將數據寫入文件緩沖區（用戶態進程的buffer)。
進程定期調用fflush()函數之后，把文件緩沖區中的文件數據寫到文件系統中，此時數據還沒有被真正寫入到物理介質中。
fsync(fileno(fp))。該函數返回后，才能保證寫入到了物理介質上。即先調用fileno獲得文件描述符之后，再調用fsync函數返回后才將文件寫入到物理介質上。

fflush和fsync的一些總結

1.提供者fflush是libc.a中提供的方法，fsync是linux系統內核提供的系統調用。
2.原形fflush接受一個參數FILE *.fflush(FILE *);fsync接受的時一個Int型的文件描述符。fsync(int fd);
3.功能fflush:是把C庫中的緩沖調用write函數寫到磁盤[其實是寫到內核的緩沖區]。fsync：是把內核緩沖刷到磁盤上。
4.fsync 將文件相關的所有更改都發送到disk device。這個調用是阻塞的，直到disk通知此函數傳輸完成。此函數也會將該文件的文件信息flush到disk。
5.fsync最終將緩沖的數據更新到文件里。

所以可以看出fflush和fsync的調用順序應該是：
c庫緩沖-----fflush---------〉內核頁高速緩存--------fsync-----〉磁盤

與文件讀寫相關的幾個重要概念

臟頁：linux內核中的概念，因為硬盤的讀寫速度遠趕不上內存的速度，系統就把讀寫比較頻繁的數據事先放到內存中，以提高讀寫速度，這就叫高速緩存，linux是以頁作為高速緩存的單位，當進程修改了高速緩存里的數據時，該頁就被內核標記為臟頁，內核將會在合適的時間把臟頁的數據寫到磁盤中去，以保持高速緩存中的數據和磁盤中的數據是一致的

內存映射：內存映射文件，是由一個文件到一塊內存的映射。Win32提供了允許應用程序把文件映射到一個進程的函數 (CreateFileMapping)。內存映射文件與虛擬內存有些類似，通過內存映射文件可以保留一個地址空間的區域，同時將物理存儲器提交給此區域，內存文件映射的物理存儲器來自一個已經存在於磁盤上的文件，而且在對該文件進行操作之前必須首先對文件進行映射。使用內存映射文件處理存儲於磁盤上的文件時，將不必再對文件執行I/O操作，使得內存映射文件在處理大數據量的文件時能起到相當重要的作用。

延遲寫（delayed write）:傳統的UNIX實現在內核中設有緩沖區高速緩存或頁面高速緩存，大多數磁盤I/O都通過緩沖進行。當將數據寫入文件時，內核通常先將該數據復制到其中一個緩沖區中，如果該緩沖區尚未寫滿，則並不將其排入輸出隊列，而是等待其寫滿或者當內核需要重用該緩沖區以便存放其他磁盤塊數據時，再將該緩沖排入輸出隊列，然后待其到達隊首時，才進行實際的I/O操作。這種輸出方式被稱為延遲寫（delayed write）（Bach [1986]第3章詳細討論了緩沖區高速緩存）。
延遲寫減少了磁盤讀寫次數，但是卻降低了文件內容的更新速度，使得欲寫到文件中的數據在一段時間內並沒有寫到磁盤上。當系統發生故障時，這種延遲可能造成文件更新內容的丟失。為了保證磁盤上實際文件系統與緩沖區高速緩存中內容的一致性，UNIX系統提供了sync、fsync和fdatasync三個函數。
sync函數只是將所有修改過的塊緩沖區排入寫隊列，然后就返回，它並不等待實際寫磁盤操作結束。
通常稱為update的系統守護進程會周期性地（一般每隔30秒）調用sync函數。這就保證了定期沖洗內核的塊緩沖區。命令sync(1)也調用sync函數。
fsync函數只對由文件描述符filedes指定的單一文件起作用，並且等待寫磁盤操作結束，然后返回。fsync可用於數據庫這樣的應用程序，這種應用程序需要確保將修改過的塊立即寫到磁盤上。
fdatasync函數類似於fsync，但它只影響文件的數據部分。而除數據外，fsync還會同步更新文件的屬性。

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

一個簡單的問題：在*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的開銷

參考：http://blog.csdn.net/cywosp/article/details/8767327

http://blog.chinaunix.net/uid-1911213-id-3412851.html

http://blog.csdn.net/lwj103862095/article/details/38268647

等

[IO系統]11 回寫機制(writeback)

在Linux-3.2新內核中，page cache和buffer cache的刷新機制發生了改變。放棄了原有的pdflush機制，改成了bdi_writeback機制。這種變化主要解決原有pdflush機制存在的一個問題：在多磁盤的系統中，pdflush管理了所有磁盤的page/buffer cache，從而導致一定程度的IO性能瓶頸。bdi_writeback機制為每個磁盤都創建一個線程，專門負責這個磁盤的pagecache或者buffer cache的數據刷新工作，從而實現了每個磁盤的數據刷新程序在線程級的分離，這種處理可以提高IO性能。

1.1 writeback機制模型

在Linux內核中有一個常駐內存的線程bdi_forker_thread，該線程負責為bdi_object創建writeback線程，同時檢測如果writeback線程長時間處於空閑狀態，bdi_forker_thread線程便會將其進行銷毀。bdi_forker_thread在系統中只有一個，其會被定時喚醒，檢查全局鏈表bdi_list隊列中是否存在dirty的數據需要刷新到磁盤。如果存在dirty數據並且對應bdi的writeback線程還沒有被創建，bdi_forker_thread會為該bdi創建一個writeback的線程進行寫回操作。

writeback線程被創建之后會處理等待的work。writeback線程擁有一個定時器會周期性喚醒這個線程處理相應的work。當用戶（page cache/buffer cache）有需要處理的inode時，將inode掛載到writeback->b_dirty鏈表中，然后喚醒writeback線程去處理相應的dirty_page。inode鏈表就是writeback線程需要處理的數據；work鏈表就是控制處理過程中的一些策略，不同的策略可以定義成不同的任務。

通過上述模型，對於塊設備或者文件系統而言，實現dirty page的后台刷新主要做如下幾個方面的工作：

1，將自己的bdi注冊到系統的bdi鏈表中，通過bdi_forker_thread實現對bdi對象的管理，從而可以實現writeback線程的動態創建、銷毀。每個塊設備和文件系統都有自己的bdi對象。Ext3文件系統在創建的時候會生成superblock對象，系統會將底層塊設備的backing_device關系到這個superblock對象上（在set_bdev_super函數中完成）。如果是塊設備的話，在add_disk的時候直接從request_queue中得到bdi對象，然后對其進行初始化。注冊bdi對象使用bdi_register_dev函數，對於ext3之類的文件系統不需要重新注冊bdi對象，因為其本身就采用了底層塊設備的bdi對象。

2，將需要刷新的inode節點掛載到bdi對象所屬的writeback->b_dirty上，如果有特殊的work需要writeback線程完成，那么提交一個work即可；如果是通常的周期性刷新，writeback線程會自動創建相應的work。

3，操作writeback的喚醒定時器延遲喚醒writeback線程，或者直接喚醒線程，從而使得inode中radix tree上的dirty page刷新到磁盤。

1.2 bdi對象的注冊

每個塊設備在創建的時候會注冊bdi對象（參見add_disk函數），這是Linux-3.2內核不同的地方。文件系統在mount的時候會創建superblock對象，並且通過底層塊設備的request queue獲取bdi對象（mount_bdev->sget->set_bdev_super）。所以，像ext3之類的文件系統都不需要重新注冊bdi對象。當然，如果文件系統重新創建了一個bdi對象，那么還需要調用bdi_register_dev函數注冊bdi對象。

1.3 小結

本文對linux-3.2中的writeback機制模型進行了闡述，后面還會對writeback機制中的關鍵函數進行分析說明。該機制是對老系統（Linux-2.6.23等）中pdflush機制的替代，其最重要的變化是每個塊設備都分配了writeback線程，使得回寫的IO流在各個磁盤之間獨立，從而從機制上提高了IO的吞吐量。

1.4 參考文獻

聊聊 Linux IO

寫在前面

如果你覺得這些問題都很簡單，都能很明確的回答上來。那么很遺憾這篇文章不是為你准備的，你可以關掉網頁去做其他更有意義的事情了。如果你覺得無法明確的回答這些問題，那么就耐心地讀完這篇文章，相信不會浪費你的時間。受限於個人時間和文章篇幅，部分議題如果我不能給出更好的解釋或者已有專業和嚴謹的資料，就只會給出相關的參考文獻的鏈接，請讀者自行參閱。

存儲器的金字塔結構

受限於存儲介質的存取速率和成本，現代計算機的存儲結構呈現為金字塔型[1]。越往塔頂，存取效率越高、但成本也越高，所以容量也就越小。得益於程序訪問的局部性原理[2]，這種節省成本的做法也能取得不俗的運行效率。從存儲器的層次結構以及計算機對數據的處理方式來看，上層一般作為下層的Cache層來使用（廣義上的Cache）。比如寄存器緩存CPU Cache的數據，CPU Cache L1~L3層視具體實現彼此緩存或直接緩存內存的數據，而內存往往緩存來自本地磁盤的數據。

本文主要討論磁盤IO操作，故只聚焦於Local Disk的訪問特性和其與DRAM之間的數據交互。

無處不在的緩存

如圖，當程序調用各類文件操作函數后，用戶數據（User Data）到達磁盤（Disk）的流程如圖所示[3]。圖中描述了Linux下文件操作函數的層級關系和內存緩存層的存在位置。中間的黑色實線是用戶態和內核態的分界線。

從上往下分析這張圖，首先是C語言stdio庫定義的相關文件操作函數，這些都是用戶態實現的跨平台封裝函數。stdio中實現的文件操作函數有自己的stdio buffer，這是在用戶態實現的緩存。此處使用緩存的原因很簡單——系統調用總是昂貴的。如果用戶代碼以較小的size不斷的讀或寫文件的話，stdio庫將多次的讀或者寫操作通過buffer進行聚合是可以提高程序運行效率的。stdio庫同時也支持fflush(3)函數來主動的刷新buffer，主動的調用底層的系統調用立即更新buffer里的數據。特別地，setbuf(3)函數可以對stdio庫的用戶態buffer進行設置，甚至取消buffer的使用。

系統調用的read(2)/write(2)和真實的磁盤讀寫之間也存在一層buffer，這里用術語Kernel buffer cache來指代這一層緩存。在Linux下，文件的緩存習慣性的稱之為Page Cache，而更低一級的設備的緩存稱之為Buffer Cache. 這兩個概念很容易混淆，這里簡單的介紹下概念上的區別：Page Cache用於緩存文件的內容，和文件系統比較相關。文件的內容需要映射到實際的物理磁盤，這種映射關系由文件系統來完成；Buffer Cache用於緩存存儲設備塊（比如磁盤扇區）的數據，而不關心是否有文件系統的存在（文件系統的元數據緩存在Buffer Cache中）。

綜上，既然討論Linux下的IO操作，自然是跳過stdio庫的用戶態這一堆東西，直接討論系統調用層面的概念了。對stdio庫的IO層有興趣的同學可以自行去了解。從上文的描述中也介紹了文件的內核級緩存是保存在文件系統的Page Cache中的。所以后面的討論基本上是討論IO相關的系統調用和文件系統Page Cache的一些機制。

Linux內核中的IO棧

由圖可見，從系統調用的接口再往下，Linux下的IO棧致大致有三個層次：

結合這個圖，想想Linux系統編程里用到的Buffered IO、mmap(2)、Direct IO，這些機制怎么和Linux IO棧聯系起來呢？上面的圖有點復雜，我畫一幅簡圖，把這些機制所在的位置添加進去：

這下一目了然了吧？傳統的Buffered IO使用read(2)讀取文件的過程什么樣的？假設要去讀一個冷文件（Cache中不存在），open(2)打開文件內核后建立了一系列的數據結構，接下來調用read(2)，到達文件系統這一層，發現Page Cache中不存在該位置的磁盤映射，然后創建相應的Page Cache並和相關的扇區關聯。然后請求繼續到達塊設備層，在IO隊列里排隊，接受一系列的調度后到達設備驅動層，此時一般使用DMA方式讀取相應的磁盤扇區到Cache中，然后read(2)拷貝數據到用戶提供的用戶態buffer中去（read(2)的參數指出的）。

整個過程有幾次拷貝？從磁盤到Page Cache算第一次的話，從Page Cache到用戶態buffer就是第二次了。而mmap(2)做了什么？mmap(2)直接把Page Cache映射到了用戶態的地址空間里了，所以mmap(2)的方式讀文件是沒有第二次拷貝過程的。那Direct IO做了什么？這個機制更狠，直接讓用戶態和塊IO層對接，直接放棄Page Cache，從磁盤直接和用戶態拷貝數據。好處是什么？寫操作直接映射進程的buffer到磁盤扇區，以DMA的方式傳輸數據，減少了原本需要到Page Cache層的一次拷貝，提升了寫的效率。對於讀而言，第一次肯定也是快於傳統的方式的，但是之后的讀就不如傳統方式了（當然也可以在用戶態自己做Cache，有些商用數據庫就是這么做的）。

除了傳統的Buffered IO可以比較自由的用偏移+長度的方式讀寫文件之外，mmap(2)和Direct IO均有數據按頁對齊的要求，Direct IO還限制讀寫必須是底層存儲設備塊大小的整數倍（甚至Linux 2.4還要求是文件系統邏輯塊的整數倍）。所以接口越來越底層，換來表面上的效率提升的背后，需要在應用程序這一層做更多的事情。所以想用好這些高級特性，除了深刻理解其背后的機制之外，也要在系統設計上下一番功夫。

Page Cache 的同步

廣義上Cache的同步方式有兩種，即Write Through（寫穿）和Write back（寫回）. 從名字上就能看出這兩種方式都是從寫操作的不同處理方式引出的概念（純讀的話就不存在Cache一致性了，不是么）。對應到Linux的Page Cache上所謂Write Through就是指write(2)操作將數據拷貝到Page Cache后立即和下層進行同步的寫操作，完成下層的更新后才返回。而Write back正好相反，指的是寫完Page Cache就可以返回了。Page Cache到下層的更新操作是異步進行的。

Linux下Buffered IO默認使用的是Write back機制，即文件操作的寫只寫到Page Cache就返回，之后Page Cache到磁盤的更新操作是異步進行的。Page Cache中被修改的內存頁稱之為臟頁（Dirty Page），臟頁在特定的時候被一個叫做pdflush(Page Dirty Flush)的內核線程寫入磁盤，寫入的時機和條件如下：

默認是寫回方式，如果想指定某個文件是寫穿方式呢？即寫操作的可靠性壓倒效率的時候，能否做到呢？當然能，除了之前提到的fsync(2)之類的系統調用外，在open(2)打開文件時，傳入O_SYNC這個flag即可實現。這里給篇參考文章[5]，不再贅述（更好的選擇是去讀TLPI相關章節）。

文件讀寫遭遇斷電時，數據還安全嗎？相信你有自己的答案了。使用O_SYNC或者fsync(2)刷新文件就能保證安全嗎？現代磁盤一般都內置了緩存，代碼層面上也只能講數據刷新到磁盤的緩存了。當數據已經進入到磁盤的高速緩存時斷電了會怎么樣？這個恐怕不能一概而論了。不過可以使用hdparm -W0命令關掉這個緩存，相應的，磁盤性能必然會降低。

文件操作與鎖

當多個進程/線程對同一個文件發生寫操作的時候會發生什么？如果寫的是文件的同一個位置呢？這個問題討論起來有點復雜了。首先write(2)調用不是原子操作，不要被TLPI的中文版5.2章節的第一句話誤導了（英文版也是有歧義的，作者在這里給出了勘誤信息）。當多個write(2)操作對一個文件的同一部分發起寫操作的時候，情況實際上和多個線程訪問共享的變量沒有什么區別。按照不同的邏輯執行流，會有很多種可能的結果。也許大多數情況下符合預期，但是本質上這樣的代碼是不可靠的。

特別的，文件操作中有兩個操作是內核保證原子的。分別是open(2)調用的O_CREAT和O_APPEND這兩個flag屬性。前者是文件不存在就創建，后者是每次寫文件時把文件游標移動到文件最后追加寫（NFS等文件系統不保證這個flag）。有意思的問題來了，以O_APPEND方式打開的文件write(2)操作是不是原子的？文件游標的移動和調用寫操作是原子的，那寫操作本身會不會發生改變呢？有的開源軟件比如apache寫日志就是這樣寫的，這是可靠安全的嗎？坦白講我也不清楚，有人說Then O_APPEND is atomic and write-in-full for all reasonably-sized> writes to regular files.但是我也沒有找到很權威的說法。這里給出一個郵件列表上的討論，可以參考下[6]。今天先放過去，后面有時間的話專門研究下這個問題。如果你能給出很明確的說法和證明，還望不吝賜教。

Linux下的文件鎖有兩種，分別是flock(2)的方式和fcntl(2)的方式，前者源於BSD，后者源於System V，各有限制和應用場景。老規矩，TLPI上講的很清楚的這里不贅述。我個人是沒有用過文件鎖的，系統設計的時候一般會避免多個執行流寫一個文件的情況，或者在代碼邏輯上以mutex加鎖，而不是直接加鎖文件本身。數據庫場景下這樣的操作可能會多一些（這個純屬臆測），這就不是我了解的范疇了。

磁盤的性能測試

在具體的機器上跑服務程序，如果涉及大量IO的話，首先要對機器本身的磁盤性能有明確的了解，包括不限於IOPS、IO Depth等等。這些數據不僅能指導系統設計，也能幫助資源規划以及定位系統瓶頸。比如我們知道機械磁盤的連續讀寫性能一般不會超過120M/s，而普通的SSD磁盤隨意就能超過機械盤幾倍（商用SSD的連續讀寫速率達到2G+/s不是什么新鮮事）。另外由於磁盤的工作原理不同，機械磁盤需要旋轉來尋找數據存放的磁道，所以其隨機存取的效率受到了“尋道時間”的嚴重影響，遠遠小於連續存取的效率；而SSD磁盤讀寫任意扇區可以認為是相同的時間，隨機存取的性能遠遠超過機械盤。所以呢，在機械磁盤作為底層存儲時，如果一個線程寫文件很慢的話，多個線程分別去寫這個文件的各個部分能否加速呢？不見得吧？如果這個文件很大，各個部分的尋道時間帶來極大的時間消耗的話，效率就很低了（先不考慮Page Cache）。SSD呢？可以明確，設計合理的話，SSD多線程讀寫文件的效率會高於單線程。當前的SSD盤很多都以高並發的讀取為賣點的，一個線程壓根就喂不飽一塊SSD盤。一般SSD的IO Depth都在32甚至更高，使用32或者64個線程才能跑滿一個SSD磁盤的帶寬（同步IO情況下）。

具體的SSD原理不在本文計划內，這里給出一篇詳細的參考文章[7]。有時候一些文章中所謂的SATA磁盤一般說的就是機械盤（雖然SATA本身只是一個總線接口）。接口會影響存儲設備的最大速率，基本上是SATA -> PCI-E -> NVMe的發展路徑，具體請自行Google了解。

具體的設備一般使用fio工具[8]來測試相關磁盤的讀寫性能。fio的介紹和使用教程有很多[9]，不再贅述。這里不想貼性能數據的原因是存儲介質的發展實在太快了，一方面不想貼某些很快就過時的數據以免讓初學者留下不恰當的第一印象，另一方面也希望讀寫自己實踐下fio命令。

前文提到存儲介質的原理會影響程序設計，我想稍微的解釋下。這里說的“影響”不是說具體的讀寫能到某個速率，程序中就依賴這個數值，換個工作環境就性能大幅度降低（當然，為專門的機型做過優化的結果很可能有這個副作用）。而是說根據存儲介質的特性，程序的設計起碼要遵循某個設計套路。舉個簡單的例子，SATA機械盤的隨機存取很慢，那系統設計時，就要盡可能的避免隨機的IO出現，盡可能的轉換成連續的文件存取來加速運行。比如Google的LevelDB就是轉換隨機的Key-Value寫入為Binlog（連續文件寫入）+ 內存插入MemTable（內存隨機讀寫可以認為是O(1)的性能），之后批量dump到磁盤（連續文件寫入）。這種LSM-Tree的設計便是合理的利用了存儲介質的特性，做到了最大化的性能利用（磁盤換成SSD也依舊能有很好的運行效率）。

寫在最后

每天抽出不到半個小時，零零散散地寫了一周，這是說是入門都有些謬贊了，只算是對Linux下的IO機制稍微深入的介紹了一點。無論如何，希望學習完Linux系統編程的同學，能繼續的往下走一走，嘗試理解系統調用背后隱含的機制和原理。探索的結果無所謂，重要的是探索的過程以及相關的學習經驗和方法。前文提出的幾個問題我並沒有刻意去解答所有的，但是讀到現在，不知道你自己能回答上幾個了？