在前文《read檔案一個位元組實際會發生多大的磁盤IO？》寫完之后，本來想著偷個懶，只通過讀操作來讓大家了解下Linux IO堆疊的各個模塊就行了，但很多同學表示再讓我寫一篇關于寫操作的，既然不少人都有這個需求，那我就寫一下吧，

Linux內核真的是太復雜了，源代碼的行數已經從1.0版本時的幾萬行，到現在已經是千萬行的一個龐然大物了，直接鉆進去的話，很容易在各種眼花繚亂的各種呼叫中迷失了自己，再也鉆不出來了，我分享給大家一個我在琢磨內核的方法，一般我自己先想一個自己很想搞清楚的問題，不管在代碼里咋跳來跳去，時刻都要記得自己的問題，無關的部分盡量少去發散，只要把自己的問題搞清楚了就行了，

現在我想搞明白的問題是，在最常用的方式下，不開O_DIRECT、不開O_SYNC（寫檔案的方法有很多，有sync模式、direct模式、mmap記憶體映射模式），write是怎么寫的，c的代碼示例如下:

#include <fcntl.h>
int main()
{
    char c = 'a';
    int out;

    out = open("out.txt", O_WRONLY | O_CREAT | O_TRUNC);
    write(out,&c,1);
    ...
}

進一步細化我的問題，我們對打開的問題寫入一個位元組后

write函式在內核里是怎么執行的?
資料在什么時機真正能寫入到磁盤上？

我們在討論的程序中不可避免地要涉及到內核代碼，我使用的內核版本是3.10.1，如果有需要，你可以到這里來下載，https://mirrors.edge.kernel.org/pub/linux/kernel/v3.x/，

write函式實作剖析

我花了不短的時候跟蹤write寫到ext4檔案系統時的各種呼叫和回傳，大致理出來了一個互動圖，當然為了突出重點，我拋棄了不少細節，比如DIRECT IO、ext4日志記錄啥的都沒有體現出來，只抽取出來了一些我認為關鍵的呼叫，

file

在上面的流程圖里，所有的寫操作最終到哪兒了呢？在最后面的__block_commit_write中，只是make dirty，然后大部分情況下你的函式呼叫就回傳了（稍后再說balance_dirty_pages_ratelimited），資料現在還在記憶體中的PageCache里，并沒有真正寫到硬碟，

為什么要這樣實作，不直接寫硬碟呢？原因就在于硬碟尤其是機械硬碟，性能是在是太慢了，一塊服務器級別的萬轉盤，最壞隨機訪問平均延遲都是毫秒級別的，換算成IOPS只有100多不到200，設想一下，假如你的后端介面里每個用戶來訪問都需要一次隨機磁盤IO，不管你多牛的服務器，每秒200的qps都將直接打爆你的硬碟，相信作為為百萬/千萬/過億用戶提供介面的你，這個是你絕對不能忍的，

Linux這么搞也是有副作用的，如果接下來服務器發生掉電，記憶體里東西全丟，所以Linux還有另外一個“補丁”-延遲寫，幫我們緩解這個問題，注意下，我說的是緩解，并沒有徹底解決，

再說下balance_dirty_pages_ratelimited，雖然絕大部分情況下，都是直接寫到Page Cache里就回傳了，但在一種情況下，用戶行程必須得等待寫入完成才可以回傳，那就是對balance_dirty_pages_ratelimited的判斷如果超出限制了，該函式判斷當前臟頁是否已經超過臟頁上限dirty_bytes、dirty_ratio，超過了就必須得等待，這兩個引數只有一個會生效，另外1個是0，拿dirty_ratio來說，如果設定的是30，就說明如果臟頁比例超過記憶體的30%，則write函式呼叫就必須等待寫入完成才能回傳，可以在你的機器下的/proc/sys/vm/目錄來查看這兩個配置，

# cat /proc/sys/vm/dirty_bytes
0
# cat /proc/sys/vm/dirty_ratio
30

內核延遲寫

內核是什么時候真正把資料寫到硬碟中呢？為了快速摸清楚全貌，我想到的辦法是用systemtap工具，找到內核寫IO程序中的一個關鍵函式，然后在其中把函式呼叫堆疊打出來，查了半天資料以后，我決定用do_writepages這個函式，

#!/usr/bin/stap
probe kernel.function("do_writepages")
{
    printf("--------------------------------------------------------\n"); 
    print_backtrace(); 
    printf("--------------------------------------------------------\n"); 
}

systemtab跟蹤以后，列印資訊如下:

 0xffffffff8118efe0 : do_writepages+0x0/0x40 [kernel]
 0xffffffff8122d7d0 : __writeback_single_inode+0x40/0x220 [kernel]
 0xffffffff8122e414 : writeback_sb_inodes+0x1c4/0x490 [kernel]
 0xffffffff8122e77f : __writeback_inodes_wb+0x9f/0xd0 [kernel]
 0xffffffff8122efb3 : wb_writeback+0x263/0x2f0 [kernel]
 0xffffffff8122f35c : bdi_writeback_workfn+0x1cc/0x460 [kernel]
 0xffffffff810a881a : process_one_work+0x17a/0x440 [kernel]
 0xffffffff810a94e6 : worker_thread+0x126/0x3c0 [kernel]
 0xffffffff810b098f : kthread+0xcf/0xe0 [kernel]
 0xffffffff816b4f18 : ret_from_fork+0x58/0x90 [kernel]

從上面的輸出我們可以看出，真正的寫檔案程序操作是由worker內核執行緒發出來的（和我們自己的應用程式行程沒有半毛錢關系，此時我們的應用程式的write函式呼叫早就回傳了），這個worker執行緒寫回是周期性執行的，它的周期取決于內核引數dirty_writeback_centisecs的設定，根據引數名也大概能看出來，它的單位是百分之一秒，

# cat /proc/sys/vm/dirty_writeback_centisecs
500

我查看到我的配置是500，就是說每5秒會周期性地來執行一遍，回顧我們的問題，我們最關心的問題的啥時候寫入的，圍繞這個思路不過多發散，于是沿著這個呼叫堆疊不斷地跟蹤，跳轉，終于找到了下面的代碼，如下代碼里我們看到，如果是for_background模式，且over_bground_thresh判斷成功，就會開始回寫了，

static long wb_writeback(struct bdi_writeback *wb,
                         struct wb_writeback_work *work)
{
	work->older_than_this = &oldest_jif;
    ...
    if (work->for_background && !over_bground_thresh(wb->bdi))
        break;
	...

    if (work->for_kupdate) {
        oldest_jif = jiffies -
                msecs_to_jiffies(dirty_expire_interval * 10);
    } else ...
}
static long wb_check_background_flush(struct bdi_writeback *wb)
{
    if (over_bground_thresh(wb->bdi)) {
   		...
        return wb_writeback(wb, &work);
    }
}

那么over_bground_thresh函式判斷的是啥呢？其實就是判斷當前的臟頁是不是超過內核引數里dirty_background_ratio或dirty_background_bytes的配置，沒超過的話就不寫了（代碼位于fs/fs-writeback.c：1440，限于篇幅我就不貼了），這兩個引數只有一個會真正生效，其中dirty_background_ratio配置的是比例、dirty_background_bytes配置的是位元組，

在我的機器上的這兩個引數配置如下，表示臟頁比例超過10%就開始回寫，

# cat /proc/sys/vm/dirty_background_bytes
0
# cat /proc/sys/vm/dirty_background_ratio
10

那如果臟頁一直都不超過這個比例怎么辦呢，就不寫了嗎？不是的，在上面的wb_writeback函式中我們看到了，如果是for_kupdate模式，會記錄一個過期標記到work->older_than_this，再往后面的代碼中把符合這個條件的頁面也寫回了，dirty_expire_interval這個變數是從哪兒來的呢？在kernel/sysctl.c里，我們發現了蛛絲馬跡，哦，原來它是來自/proc/sys/vm/dirty_expire_centisecs這個配置，

1158         {
1159                 .procname       = "dirty_expire_centisecs",
1160                 .data           = https://www.cnblogs.com/kfngxl/p/&dirty_expire_interval,
1161                 .maxlen         = sizeof(dirty_expire_interval),
1162                 .mode           = 0644,
1163                 .proc_handler   = proc_dointvec_minmax,
1164                 .extra1         = &zero,
1165         },

在我的機器上，它的值是3000，單位是百分之一秒，所以就是臟頁過了30秒就會被內核執行緒認為需要寫回到磁盤了，

# cat /proc/sys/vm/dirty_expire_centisecs
3000

結論

我們demo代碼中的寫入，其實絕大部分情況都是寫入到PageCache中就回傳了，這時并沒有真正寫入磁盤，我們的資料會在如下三個時機下被真正發起寫磁盤IO請求：

第一種情況，如果write系統呼叫時，如果發現PageCache中臟頁占比太多，超過了dirty_ratio或dirty_bytes，write就必須等待了，
第二種情況，write寫到PageCache就已經回傳了，worker內核執行緒異步運行的時候，再次判斷臟頁占比，如果超過了dirty_background_ratio或dirty_background_bytes，也發起寫回請求，
第三種情況，這時同樣write呼叫已經回傳了，worker內核執行緒異步運行的時候，雖然系統內臟頁一直沒有超過dirty_background_ratio或dirty_background_bytes，但是臟頁在記憶體中呆的時間超過dirty_expire_centisecs了，也會發起會寫，

如果對以上配置不滿意，你可以自己通過修改/etc/sysctl.conf來調整，修改完了別忘了執行sysctl -p，

最后我們要認識到，這套write pagecache+回寫的機制第一目標是性能，不是保證不丟失我們寫入的資料的，如果這時候掉電，臟頁時間未超過dirty_expire_centisecs的就真的丟了，如果你做的是和錢相關非常重要的業務，必須保證落盤完成才能回傳，那么你就可能需要考慮使用fsync，

file

開發內功修煉之硬碟篇專輯：

1.磁盤開篇：扒開機械硬碟堅硬的外衣！
2.磁盤磁區也是隱含了技術技巧的
3.我們怎么解決機械硬碟既慢又容易壞的問題？
4.拆解固態硬碟結構
5.新建一個空檔案占用多少磁盤空間？
6.只有1個位元組的檔案實際占用多少磁盤空間
7.檔案過多時ls命令為什么會卡住？
8.理解格式化原理
9.read檔案一個位元組實際會發生多大的磁盤IO？
10.write檔案一個位元組后何時發起寫磁盤IO？
11.機械硬碟隨機IO慢的超乎你的想象
12.搭載固態硬碟的服務器究竟比搭機械硬碟快多少？

我的公眾號是「開發內功修煉」，在這里我不是單純介紹技術理論，也不只介紹實踐經驗，而是把理論與實踐結合起來，用實踐加深對理論的理解、用理論提高你的技術實踐能力，歡迎你來關注我的公眾號，也請分享給你的好友~~~

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/204214.html

標籤：PHP

上一篇：確認! Python奪冠，80%的程式員：痛快！你怎么看？

下一篇：機械硬碟隨機IO慢的超乎你的想象

write檔案一個位元組后何時發起寫磁盤IO

write函式實作剖析

內核延遲寫

結論