共計 3172 個字符，預計需要花費 8 分鐘才能閱讀完成。

這篇文章主要講解了“linux 的數據一致性和 io 類型怎么理解”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“linux 的數據一致性和 io 類型怎么理解”吧！

對 linux 內核來說，讀寫要經過層層路徑，才能真正讀寫硬盤。從 io 路徑來說，io 要經過 page cache，io 調度隊列，dispatch 隊列，ncq 隊列和硬盤 cache，才能真正到達硬盤。

Page cache：page cache 是 linux 內核提供的緩存接口，page cache 的名字就說明內核是通過 page 單元（通常 4K 大小）來管理 cache。讀操作首先在 page cache 查找，如果找到，就復制 page cache 的內容返回，找不到，才真正調用下層處理。寫操作，buffer io 寫到 page cache 就返回，真正的磁盤寫，是由內核的 pdflush 內核線程負責

IO 調度隊列：

Linux 內核提供了四種 io 調度算法，as,deadline,cfq,noop。每種調度算法都實現了一個調度隊列，io 首先在隊列中排序（noop 最簡單，不排序），然后根據條件，決定是否到 dispatch 隊列。從調度隊列下發，涉及一個 unplug 的概念。也就是說，調度隊列通常處于阻塞（plug）狀態，當執行 unplug 操作時，io 離開調度隊列，開始下發。unplug 是個循環動作，將調度隊列的所有 io 都嘗試下發，直到不能下發為止。
總結一下，執行 unplug 有下列條件：

第一個 io 啟動了三毫秒的定時器，定時器到了，會 unplug，開始下發

io 請求超過設定的限制（缺省是 4），執行 unplug，開始下發

Sync 標志的 io，立即 unplug，開始下發。

Barrier 標志的 io，清空調度隊列后，執行 unplug，開始下發

一個 io 執行完畢，也要 unplug 隊列。

dispatch 隊列：dispatch 隊列對應用關系不大。但是內核層對日志文件系統的 joural 數據，提供了一種 barrier io，這個主要在 dispatch 隊列實現。

Ncq 隊列：
NCQ 是 sata 硬盤自身的隊列。（sas 硬盤的隊列叫 TCQ）。NCQ 隊列是由操作系統創建的，但是加入到 NCQ 隊列的 io，是由硬盤來決定執行順序。為了實現這個，NCQ 隊列創建在內核的 DMA 內存中，然后通知硬盤，至于硬盤選擇那個 io 執行，是硬盤自身選擇的結果。

硬盤 cache:
硬盤 cache 是硬盤內部的 cache。如果打開硬盤 cache 的話，寫硬盤的 io，首先是到硬盤 cache，而非直接落到硬盤。

一. Pdflush 的回寫邏輯

Pdflush 提供了四個參數來控制回寫。在內核實現中，pdflush 的回寫策略控制還比較復雜。

但是簡單一點說，內核缺省情況下，每 5 秒鐘掃描臟頁，如果臟頁生存時間超過 30 秒（缺省數值），就刷臟頁到磁盤。

詳細的可參考本人寫的《linux 內核回寫機制和調整》一文。

二. 數據下盤和一致性分析

從上文的分析，通常的 io 寫，到 page cache 層就結束返回了，并沒真正寫到硬盤。這樣機器掉電或者故障的時候，就有丟失數據的風險。為了盡快下 io，系統又提供了一些措施解決這個問題。

O_SYNC: 打開文件的時候，可以設置 O_SYNC 標志，在 page cache 的寫完成后，如果文件有 O_SYNC 標志，立即開始將 io 下發，進入調度隊列。隨后將文件系統的 meta data 數據也下發，然后開始循環執行 unplug 操作，直到所有的寫 io 完成。和回寫機制比較，O_SYNC 沒有等臟頁生存 30 秒，就嘗試立即下發到硬盤。

O_SYNC 本質就是 io 下發，然后執行 unplug 操作。O_SYNC 的幾個問題是：

寫 page cache 時候要把 io 拆成 4k 的單元。回寫也是每次寫 4K 的頁面，如果是大 io，就需要內核的調度層把 4k 的 io 重新再合并起來。這是冗余的過程

每個 io 都要立即 unplug，這樣就不能實現 io 的排序和合并。O_SYNC 的性能相當低。

如果多個進程并發寫，不能保證寫操作的順序。Ncq 隊列根據硬盤磁頭的位置和磁盤旋轉位置確定執行的順序。一般是 meta data 數據一起寫，這樣存在不同步的風險。

如果硬盤 cache 打開了，那么寫只到硬盤 cache 就返回了。存在丟數據的風險。通常存儲廠商都要求硬盤 cache 關閉。不過騰訊的服務器都是打開硬盤 cache 的。

O_DIRECT：打開文件的時候，可設置 O_DIRECT 標志。O_DIRECT 不使用內核提供的 page cache。這樣讀操作，就不會到 page cache 中檢查是否有需要數據存在。而寫操作，也不會將數據寫入 page cache，而是送入調度隊列。

O_DIRECT 執行寫 io 的時候，會置 WRITE_SYNC 標志。這個標志在 io 進入調度隊列后，會執行一次 unplug 操作。而不是像 O_SYNC 那樣，循環執行 unplug 操作。

為了避免 O_SYNC 每個寫 io 都要阻塞等待的問題，系統提供了 fsync 和 fdatasync 系統調用，可以讓應用層自己控制同步的時機。

Fsync：fsync 將文件范圍內，所有的臟頁面都下發到硬盤。然后也要將臟的元數據寫到 硬盤。如果文件的 inode 本身有變化，同樣需要寫到硬盤。

Fdatasync：fdatasync 和 fsync 的區別其實很輕微。比如 ext2 文件系統，如果文件的 inode 只有輕微的變化，fdatasync 此時不更新 inode。典型的輕微變化是文件 atime 的變化。而在 ext3 文件系統，fsync 和 fdatasync 是完全一樣的。不管是否輕微變化，都要回寫 inode。

Fsync 和 fdatasync 都是對整個文件的操作，如果應用只想刷新文件的指定位置，這兩個系統調用就失效了。所以新的內核還提供了 sync_file_range 來指定范圍寫。不過要注意，sync_file_range 是不回寫文件的 meta data。必須應用層保證 meta data 沒有更新。

三. Pdflush 的回寫邏輯

Pdflush 提供了四個參數來控制回寫。在內核實現中，pdflush 的回寫策略控制還比較復雜。

但是簡單一點說，內核缺省情況下，每 5 秒鐘掃描臟頁，如果臟頁生存時間超過 30 秒（缺省數值），就刷臟頁到磁盤。

四. 內核的 barrier io

從上文的分析看出，內核沒有為用戶態提供保證順序的，確定寫到硬盤的系統調用。但是對于內核文件系統來說，必須提供這樣的接口。比如日志文件系統，必須要數據落到硬盤后，才能修改元數據的日志。否則，出錯情況下就可能造成文件系統崩潰。為此，內核專門提供了一個 barrier 方式實現日志的準確寫到硬盤。

文件系統的 barrier io，意味著，這個 barrier io 之前的寫 io 必須完成。同時，在 barrier io 完成之前（是真正寫到硬盤，不是寫到 cache 就返回），也不能有別的寫 io 再執行。為此，上文分析的 dispatch 隊列完成了這個功能。

當寫 io 從調度隊列進入 dispatch 隊列的時候，要檢查是否是一個 barrier io。如果是 barrier io，dispatch 首先在隊列中插入一個 SCSI 命令 SYNCHRONIZE_CACHE，這個命令指示硬盤 cache 刷所有的寫 io 到硬盤。然后再下發 barrier io，之后再插入一個 SYNCHRONIZE_CACHE 命令，指示硬盤將剛才的 barrier io 真正寫到硬盤（還有一種方式，是通過命令攜帶 FUA 標志實現不經過 cache 直接下盤）。

感謝各位的閱讀，以上就是“linux 的數據一致性和 io 類型怎么理解”的內容了，經過本文的學習后，相信大家對 linux 的數據一致性和 io 類型怎么理解這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！