另一方面所有更現代的 FS 設計（包括 xfs 和 btrfs ）都在一開始就採用了 extent based mapping 和 delayed allocation ，這方面 ext4 雖然是後來的實踐者，確實也是把 delayed allocation 推向大衆的最大推動者。

對 fs 做 benchmark 這事情，我覺得換個領域類比一下大概能描述我現在的感受。就像假設有個博客隔幾個月拉來 3dmark glmark 分別在各個發行版的默認安裝的 gnome kde xfce 上跑一下，每個 mark 出個幀數柱狀圖，坐標軸是 gnome kde xfce 。仔細看 footnote 還會發現這博客跑的時候有的在 wayland 有的在 xorg ，有的全屏有的窗口，有的開著混成有的沒開，博主給的理由是為了衡量各個發行版開箱即用得到的體驗。看到這種博客是不是會感覺這博主啥都不懂在瞎測？結果時間久了經常有朋友跑來問 gnome kde xfce 哪個 3d 性能好，是不會產生“為啥會想用 3d 性能評價桌面環境？”的疑惑。再時間久了經常有人拿著那個博客跑來說 gnome 3d 性能不行啊，是不是會感覺很無奈想要反駁一下這個視角錯了…對最終用戶而言3d性能固然很重要，對kwin和mutter開發者們而言性能測試固然也很有意義，但是從用戶角度只看3d性能去選桌面環境是不是就很無厘頭了。我現在看 phoronix 的 fs 測評也就是這種感覺。我覺得搞這測評本身就沒啥價值，衡量的方式和衡量的對象都有問題

關於斷電保護之前的這篇介紹也很不錯

關於 ext4 新的 fast commit 之前的 lwn 文章

https://youtu.be/TMjgShRuYbg FreeBSD FFS 簡介，Kirk McKusick 在很多地方講過這個，FAST15 這段錄製的畫質最好

似乎我上面關於文件系統如何記錄日誌來保證一致性的描述太過細節，沒有很好地描述整體上的原理，還是針對具體問題補充一下。

問：假設 ext4 文件系統中有個 100KiB 的文件，現在程序在文件後面接着寫入了 100KiB ，寫入過程中斷電了，Ext4 如何保證這個寫入是完整的？
短回答： ext4 不保證，ext4 不關心文件的數據是完整的，只關心和保證 ext4 自己的元數據是完整的。
長回答：

假設如上場景，寫入 100KiB 過程中，甚至 100KiB 寫完(write syscall正常返回）之後發生了突然斷電，然後正常啓動系統，在文件系統回放完日誌之後，可能發生如下結果：
1. 文件長度還是 100KiB
2. 文件長度是 130KiB
3. 文件長度是 200KiB ，但是後面 100KiB 內容是全0或者是垃圾數據
4. 文件長度是 200KiB ，後面 100KiB 內容是程序寫入的數據
如上結果都有可能發生。根據具體文件系統記錄日誌的方式，可能一部分情形在特定條件下不會發生。文件系統的一致性保證的是不會發生下述情況：
a. 文件長度增加了 100KiB 變成 200KiB ，但是文件內容的塊列表還是 100KiB 的塊。
b. 文件內容的塊列表多了 100KiB 的塊，總長度變成了 200KiB ，但是文件系統的可用空間沒有減少 100KiB
c. 文件內容的塊列表多了 100KiB 的塊，但是這 100KiB 同時也被別的文件的塊列表引用着，兩個文件同時共享了一部分塊。
上述這些情況是文件系統需要用日誌保證的一致性。另一方面，如果 write syscall 之後，程序調用 fsync 要求文件系統刷新文件內容到盤上，在 fsync 正常返回之前如果發生了突然斷電，那麼仍然可能發生上面 1-4 的寫入一半的情況。如果 fsync 返回之後突然斷電，那麼正常日誌回放之後可以保證文件變成了 200KiB ，內容也是程序寫入的內容。具體 fsync 要求文件系統做出什麼級別的保證取決於具體的文件系統，ext4/xfs/btrfs 之類的實現各有不同。

具體到 ext4 的情況，在默認開啓了日誌並且 data=ordered 的掛載選項的前提下，發生的事情大概是：
1. 程序發出 write syscall ，write 把程序要寫入的內容從程序的內存拷貝到內核的 pagecache 緩衝區中，同時修改了內存中的 inode 的長度，但是不會把 inode 寫入到盤上。
2. 此時因爲 ext4 的 delayed allocation （ext3沒有延遲分配，xfs和btrfs也會延遲分配。一般使用 extent 表達內容地址的文件系統都會有延遲分配策略），這些緩衝區並沒有對應的塊地址，內容就留在內核的內存頁面裏。
3. 內存壓力下，或者超過了 commit_interval ，或者接到了程序的 fsync/fdatasync 請求，分配不能再拖延下去的時候， ext4 調用塊分配器給上面 write 寫入的頁面安排好塊地址，交給 block io 往盤上寫入。
4. 因爲 data=ordered ，寫入完之後開始考慮更新 inode 和文件系統可用空間之類的元數據。在 journal 中開啓一個新事務，把 inode 所在塊，和可用空間記錄（block group 的 block bitmap ）寫入 journal ，然後提交事務。
5. 等事務提交完落盤之後，再把 inode 和可用空間記錄慢慢寫回到 ext4 自己的 inode table 和 block group 描述的地方。
如果事務提交之後，發生突然斷電，正常開機並且回放日誌的時候會保證日誌中記錄的事務會再次寫到正確的地方去

https://openzfs.topicbox.com/groups/developer/T950b02acdf392290/odirect-semantics-in-zfs O_DIRECT semantics notes in zfs

https://github.com/openzfs/zfs/pull/10018 PR for DirectIO in openzfs

https://github.com/pjd/openzfs/commit/184c9e78733381c7cc4f0b18e9d6819a6f3c1c66 BRT based reflink implementation (copy_file_range) for openzfs , about to PR hopefully

https://github.com/openzfs/zfs/pull/13392 openzfs 基於 BRT 的 block cloning (reflink) 終於 merge 了