btrfs-progs 專案案例研究：嚴重損毀 12TB 多裝置儲存集區的救援與分析

這不是一個錯誤報告。這是一份關於嚴重損毀的 12TB 多裝置儲存集區救援工作的案例研究報告，在此分享，以防任何觀察結果對 btrfs-progs 的開發有所助益。目標是建設性的，而非抱怨。

一個 3 裝置集區（資料單份、中繼資料 DUP、DM-SMR 硬碟）的硬體強制重啟，導致 extents tree 和 free space tree 處於無法透過原生修復路徑解決的狀態。隨後的 btrfs check --repair 執行進入了無限循環，超過 46,000 次提交但淨進度為零，將 4 個 backup_roots 插槽輪播到任何崩潰前的回滾點。最終透過一套針對內部 btrfs-progs API 建置的 14 個客製化 C 工具成功完成救援，最終資料損失約 4.59 TB 中的 7.2 MB（0.00016%）。該集區現已完全正常運作。

我以結構化的方式撰寫了此案例，涵蓋了環境、時間線、根本原因分類、我們透過實證得出的安全標準，以及 9 個特定領域，其中相對較小的上游變更本可以避免大多數客製化工具的需要。

https://github.com/msedek/btrfs_fixes/blob/main/INCIDENT-ANALYSIS.md

九個建議的改進領域，依據對遇到類似案例的操作員預期影響的順序排列：

所有 14 個客製化工具，以及 alloc_reserved_tree_block 的單行修補程式，均以 GPL-2.0 形式發佈於：

https://github.com/msedek/btrfs_fixes

每個工具預設都具有唯讀掃描模式，以及一個需要選擇加入的 --write 模式。README.md 解釋了救援期間使用的執行順序。我並不打算直接將這些作為上游修補程式提交。大多數上述建議並非單一函數的變更，要接受任何一項都需要與對所涉及子系統比我更熟悉的人進行設計討論。分享參考實施比在沒有上下文的情況下開啟九個獨立的提取請求感覺更有用。

請將此視為輸入，而非要求。如果任何單一觀察或建議值得追求，我很樂意擴展分析、提供會話日誌中的額外證據，或針對我們遇到的損壞類型測試任何建議的修補程式。如果沒有任何內容有用，也沒關係，感謝讓我們先走了一大段路的工具集。