https://openzfs.org/wiki/OpenZFS_Developer_Summit_2021_talks#ZFS_on_Object_Storage_.28Delphix_Team.29 zfs on s3 這個 talk 挺有意思的

https://youtu.be/3opWuc-M2hY 1:40:00 附近開始

tldr: 1. 把 block group extent 從 extent tree 拆出來形成單獨的 bg tree 2. 全局 tree root 按 CPU 數拆成多組 tree root ，減少全局鎖競爭

1 的優點：掛載快（不需要讀很多 extent tree leaf 了），寫放大減小。2 的優點：多核上並行性更好了。缺點：格式變更需要遷移…

josef 說這只是第一部分，還會有更多變化

感覺細節上和博客裡定稿的內容有點不一樣，視頻裡說想搞 per bg 的 tree root，博客裡變成了 per CPU 的。另外提到了博客裡沒寫的變化：3. relocation tree 改 remap tree ，4. snapshots tracking

總結：現代系統上，針對 SSD（SATA/SAS/nvme）而言，文件系統性能只要足夠，就不需要比較性能有多好了，別的方面的差異比性能更重要。
感想：實際上比較文件系統性能的 benchmark 也很容易誤導。文件系統按其功能定義是有狀態的，benchmark 為了“公平”起見通常會測量全新狀態下的性能表現，而這通常有別於使用一段時間之後的性能。

https://lore.kernel.org/lkml/YhIwUEpymVzmytdp@casper.infradead.org/ 內核在討論要不要移除 reiserfs ，RIP

關於文件系統如何保證斷電時的一致性：記錄日誌（journaling）、軟更新（soft updates）、日誌式結構（log-structured）、A/B更新、寫時拷貝（copy on write）
（先挖個坑，一會兒亂序慢慢填，記錄一下思緒，說不定以後會整理成博客）

介紹這些斷電保護機制之前可能需要先解釋一下為啥需要斷電保護，畢竟有些上古的文件系統（比如 fat 系）貌似完全沒有這方面設計似乎也活得好好的。之前解釋硬盤演化的坑裡說過，早期軟盤硬盤可以完全沒有控制芯片，純粹靠CPU“驅動”，那個年代尤其是 DOS 下沒有多程序並發的寫入，程序調用 DOS 終端寫一個文件，DOS 就調用對應 IO 的中斷，按文件系統的邏輯順序寫東西，CPU控制下寫的東西只有一個當前位置，所以如果寫入過程中突然斷電也只是最多有一個扇區存在寫入一半的狀況，導致文件系統的不一致性可能發生在一個扇區。所以這種時候 chkdsk 檢查和修復就足以應對了。Unix時代早期的 fs 也幾乎是這個思路，雖然 Unix 有並發多進程，不過內核部分還是不可重入的，所以寫入文件系統的代碼基本可以保證寫入順序，然後發生了突然斷電就依靠 fsck 修文件系統的不一致。

說到文件系統的不一致，可能很多地方提過 fsck/chkdsk 可以修它，但是沒說過具體不一致是指什麼意思，又是怎麼修的。比方說程序在 4K 簇大小的 fat32 上創建文件 c:\abc\def.txt 寫了兩個簇的數據，DOS接到這個文件系統的寫入調用，實際要做的事情是在 fat32 好幾個位置寫東西：
a. 找到 abc 這個文件夾所在的簇，往文件夾裡添加一個文件表項 def.txt 記錄下創建時間、文件名、文件長度之類的元數據
b. 掃描 fat 找兩個空簇，寫入 fat 文件分配表，把這倆簇號連成一個單鍊錶
c. 把文件數據實際寫入這倆簇裡
d. 把起始簇號寫到 abc 文件夾的 def.txt 文件表項裡
e. 調整可用簇計數，寫入到 fat 開頭的 vbr（superblock）
實際上述寫入的順序可能不是我列出來的順序，不過大體上是要按照某個順序在不同的偏移處寫入這些東西。考慮在上述寫入過程中斷電的話，那麼可能發生幾種不一致（不完全列表，只是臨時想到的）：
1. 文件表項說 def.txt 長度有倆簇，但是起始地址卻是空的。
2. 文件表項說 def.txt 的起始簇號是 0x100 ，但是 fat 文件分配表中記錄的 0x100 狀態卻是未佔用
3. fat文件分配表中 0x100 和 0x104 倆簇形成單鍊錶已佔用的狀態了，但是未能成功寫入 def.txt 文件表項，整個文件夾樹中沒有文件的起始簇號是 0x100 。
4. 把兩簇號記錄為了已佔用的單鍊錶，但是 vbr 中的已佔用計數沒有減2。
等等情況，也就是一部分寫入成功了而另一部分寫入失敗了的話，散佈在文件系統中不同地方的記錄出現了偏差。
這時對 fat32 做 chkdsk ，它會去檢查 fat32 上述各個元數據是否合理，試圖修復一致性。比如：
1. 發現 def.txt 的起始簇號是 0x100 ，0x100 下一個簇是 0x104 ，0x104 是單鍊錶末尾。但是 def.txt 的文件長度是0字節：這時可以修改文件長度為 8K ，雖然正確的文件長度可能不到 8K ，於是文件末尾多了一些字節的垃圾。
2. 發現 0x100 和 0x104 構成一個單鍊錶，但是文件夾樹中沒有文件的起始簇號是 0x100 ，那麼只能創建一個新文件叫 RECOVER1 放在根目錄去，內容指向 0x100 。
3. 發現 vbr 中記錄的已用簇計數比 fat 文件分配表中實際佔用的簇少了 2 ，這時去調整 vbr 中的計數。
總之 chkdsk 依賴於知曉 fat32 寫入時修改元數據的具體順序，然後基於它看到的實際情況，做合理或不合理的猜測，假定突然斷電發生時，已經產生了哪些寫入，還未產生哪些寫入，猜測哪邊大概是正確的然後調整另一邊。
有的時候chkdsk發現的問題的修復方式不是那麼顯然的，比如如果 fat 中 0x100 和 0x102 記錄的下一簇都是 0x104 ，也就是說有兩個不同文件“共享”了同一個結尾，那麼必然需要犧牲一個文件的內容，砍斷尾巴，使所有文件在 fat 中的記錄都成為單鍊錶。
可見 chkdsk 修復文件系統一致性的方式，並不在意“正確性”，只在意不同位置的數據之間是否合乎邏輯，避免文件系統其餘地方的代碼遇到邏輯上不一致的 bug 。“修復一致性”這個操作，有時是可以搶救數據的，有時是會破壞數據的，目標只是還原到“一致”的狀態。