重新認識 Linux 的 iomap 層：檔案系統擺脫 buffer_head 的關鍵抽象
Linux Kernel Documentation / LWN.net · 2026-07-06
LWN 在 2026 年 7 月 6 日刊出一篇深入介紹 Linux 核心 iomap 層的技術文章，回顧這個自 XFS 開發者 Christoph Hellwig 主導設計以來、逐步取代傳統 buffer_head 機制的區塊 I/O 抽象層。iomap 目前已寫入核心正式文件 Documentation/filesystems/iomap/，成為新檔案系統實作區塊對應（block mapping）時的建議介面。
背景
傳統 Linux I/O 模型以固定大小的頁面或區塊為單位，每次操作都要向檔案系統個別查詢儲存空間對應，查詢成本會隨著檔案操作被拆得越細而不斷疊加。iomap 反其道而行：它要求檔案系統一次回傳「能建立的最大範圍對應」，再以此範圍執行實際 I/O，藉此把對應函式呼叫的成本攤提到更大量的資料上。這個模型從 XFS 起家，逐步擴散到 ext4、Btrfs 等主流檔案系統；核心 5.5 與 5.8 版讓 ext4、Btrfs 相繼採用 iomap 處理直接 I/O，6.6 版加入大型 folio 的逐區塊髒頁追蹤，6.9 版則引入 writeback 範圍的多區塊對應最佳化。
核心改動
iomap 的核心資料結構是 struct iomap，用來描述一段檔案位移範圍對應到哪一段裝置位址：
struct iomap {
u64 addr; /* 裝置位元組位址 */
loff_t offset; /* 檔案位移（bytes）*/
u64 length; /* 範圍長度（bytes）*/
u16 type; /* IOMAP_HOLE / IOMAP_MAPPED ... */
u16 flags; /* IOMAP_F_NEW / IOMAP_F_DIRTY ... */
struct block_device *bdev;
void *inline_data; /* IOMAP_INLINE 專用 */
void *private;
u64 validity_cookie; /* 陳舊對應偵測 */
};type 欄位區分 IOMAP_HOLE（未配置空間，寫入時視為錯誤）、IOMAP_DELALLOC（延遲配置的承諾）、IOMAP_MAPPED（已配置且有實際位址）、IOMAP_UNWRITTEN（已配置但未初始化，讀取時視同全零）與 IOMAP_INLINE（資料直接內嵌在 inode metadata）。檔案系統只需實作兩個回呼函式就能整合進 iomap 架構：
int (*iomap_begin)(struct inode *inode, loff_t pos, loff_t length,
unsigned flags, struct iomap *iomap,
struct iomap *srcmap);
int (*iomap_end)(struct inode *inode, loff_t pos, loff_t length,
ssize_t written, unsigned flags, struct iomap *iomap);iomap_begin 只需要涵蓋所要求範圍的第一個位元組即可回傳，不必一次涵蓋整段；flags 參數會標明操作型態，例如 IOMAP_DIRECT（區塊裝置直接 I/O）、IOMAP_DAX（記憶體式裝置）與 IOMAP_NOWAIT（非阻塞嘗試，須阻塞時回傳 -EAGAIN）。iomap_end 則在 I/O 完成後被呼叫，供檔案系統釋放預留空間、更新 metadata。
影響範圍
iomap 對鎖定策略不做任何強制規定，檔案系統可以自由選擇在 iomap_begin/iomap_end 內採用自己的鎖，文件將整體鎖定階層分為 VFS 層（i_rwsem、folio lock）、檔案系統對應層與 iomap 內部操作層三級。iomap 目前支援 pagecache 讀寫、folio 寫入缺頁例外、髒 folio 回寫、直接 I/O、fsdax I/O、FIEMAP 回報與 lseek 的 SEEK_DATA/SEEK_HOLE，但仍不支援 fscrypt 加密、壓縮與 fsverity 驗證——文件坦言這個模型仍帶有「假設 I/O 應該長得像 XFS 那樣」的先天傾向。目前 Hellwig 正與 Namjae Jeon 合作，將 exFAT 的資料路徑轉換為使用 iomap，作為後續其他檔案系統轉換的範本。
原始來源：Linux Kernel Documentation — iomap Library Design、LWN: Filesystems and iomap
Linux 7.2-rc2 釋出：mod_devicetable.h 大拆分成為本輪最大變動
LWN.net / Linus Torvalds 核心公告 · 2026-07-05
Linus Torvalds 於 2026 年 7 月 5 日發布 Linux 7.2-rc2，作為 7.2 開發週期的第二個候選版本。Torvalds 在公告信中表示這個 rc2 「不算小，但符合近期慣例，甚至比 7.1 的 rc2 還略小一些」，整體開發節奏正常，超過半數修補集中在驅動程式，其餘分散在檔案系統與網路子系統。
核心改動
本輪最顯著的改動並非新功能，而是 Uwe Kleine-König 主導的 mod_devicetable.h 大拆分：這支長期充當「巨獸標頭檔」的檔案，被拆成多個依子系統劃分的裝置 ID 標頭檔，牽動的修補集數量超過 1,500 個。Torvalds 形容這個變動「有點不尋常」，但本質上是一次清理工作：
- 拆分後修改單一子系統的裝置 ID 定義，不再需要重新編譯幾乎整個核心樹
- 減少了
mod_devicetable.h這類「牽一髮動全身」標頭檔案的數量 - 變動規模雖大，但屬於機械式的結構調整，而非邏輯行為變更
除此之外，本輪 shortlog 涵蓋約 300 多位開發者的貢獻，主要集中在 DRM/GPU 驅動（AMD、Intel Xe、ARM 相關）、網路協定堆疊與多個檔案系統的臭蟲修正，整體屬於典型的 rc2 階段修補分布。
影響範圍
依照目前的開發節奏，rc3 預計於下週釋出，穩定化窗口將持續進行，7.2 正式版預估落在 8 月底至 9 月初之間，符合近幾個發行週期的一貫排程。對維護樹外模組或驅動程式的開發者而言，mod_devicetable.h 拆分後需要留意 #include 路徑的相依調整，這是本輪 rc 對外部程式碼相容性影響最大的部分。
原始來源：LWN: Kernel prepatch 7.2-rc2、torvalds/linux: mod_devicetable.h
Rust 1.96.1 修補版釋出：修正 MIR 優化誤編譯與 libssh2 三項 CVE
Rust GitHub Releases · 2026-07-05
Rust 專案於 2026 年 7 月 5 日發布 1.96.1 修補版，針對上一版 1.96.0 釋出後發現的一個編譯器誤編譯（miscompilation）臭蟲，以及 Cargo 依賴的 libssh2 函式庫三項安全漏洞進行修正。此版本同時回溯進入 1.97.0 的 beta 分支。
核心改動
最關鍵的修正是 rustc MIR 優化通道 SimplifyComparisonIntegral 的誤編譯問題，對應 rust-lang/rust#158214。這個優化通道原本的邏輯是：當比較結果會被折疊進 switchInt 分支跳轉時，嘗試移除多餘的賦值陳述式。問題在於它沒有檢查同一個基本區塊（basic block）內是否還有其他地方用到該比較結果，導致仍在使用中的暫存賦值被誤刪。更深層的問題是，該通道原先假設 Operand::Move 語意能保證暫存變數之後處於未初始化狀態，但這個假設本身並不足以支撐這種清理邏輯的正確性。PR 說明中提到，在不做全函式分析（whole-function analysis）的前提下，目前沒有辦法安全地保留這個優化，因此修法是直接移除這段有問題的邏輯，而非嘗試修補它。
此臭蟲已確認影響 1.96.0 穩定版，修正已回溯進入 1.96.1；beta 分支的 1.97.0 也包含同一修正；nightly 分支則已在 2026 年 6 月 22 日併入主線。
其他修正
- Cargo 修正逾時／重試（timeout/retry）行為異常，對應
rust-lang/cargo#17131 - Cargo 對其內建的 libssh2 函式庫套用安全修補，修正
CVE-2025-15661、CVE-2026-55199、CVE-2026-55200三項漏洞，對應rust-lang/cargo#17140
由於本次修正涉及編譯器輸出正確性而非單純的功能新增，Rust 專案將其獨立為 1.96.1 修補版本快速釋出，而非等待下一個 6 週例行大版本週期。