案例研究：修復嚴重損壞的 12 TB 多裝置儲存池

背景

這篇技術報告詳述了一次針對 12 TB Btrfs 多裝置磁碟陣列的極限救援行動。該系統在一次硬體斷電後，因中斷了元數據寫入導致檔案系統嚴重損毀，原生修復工具不僅無法修復，甚至陷入無限迴圈並覆蓋了備份根節點。作者最終透過自行開發的 14 個 C 語言工具，成功救回 99.99% 的數據，並將此過程整理成案例研究提交給開發團隊，旨在提出建設性的改進建議而非單純抱怨。

社群觀點

這起事件在 Hacker News 引發了關於檔案系統可靠性與現代修復手段的熱烈討論。許多網友對 Btrfs 的穩定性表示擔憂，認為一個標榜「生產環境就緒」的檔案系統，若在斷電後需要使用者具備編寫自定義 C 語言工具的能力才能找回數據，對一般用戶而言門檻過高且難以接受。部分留言者直言，這種情況讓他們對 Btrfs 望而卻步，並質疑為何像寫入時複製（CoW）這類應能確保原子性的機制，在現實案例中卻未能防止元數據不一致的發生。

討論中也出現了關於這篇報告生成方式的爭議。有讀者懷疑該報告與修復工具可能是在大型語言模型（LLM）的協助下完成的，甚至有人推測這是一次 LLM 自主修復檔案系統的實驗。然而，這種觀點遭到反駁，支持者認為報告的結構與細節更像是專業工程師的實戰紀錄，而非 AI 生成的內容。儘管如此，社群普遍認同作者採取「建設性分析」而非「憤怒投訴」的態度非常難得，這種將失敗經驗轉化為具體改進建議的做法，有助於開發者理解現有工具鏈的盲點。

此外，社群也針對不同檔案系統的健壯性進行了橫向比較。有觀點提到 ZFS 雖然也曾出現過加密磁碟區或記憶體不足時的掛起問題，但在處理斷電導致的損毀上通常有更成熟的表現。爭論的核心在於，如果檔案系統在官方文件中沒有明確標註斷電可能導致全盤崩潰的風險，那麼當災難發生時，開發團隊應負起更多責任。網友們期待 Btrfs 開發者能針對此案例給出回應，確認這究竟是罕見的硬體異常，還是檔案系統架構中尚未修補的邏輯漏洞。

延伸閱讀

在討論過程中，有網友提到了 bcachefs 作為另一種現代檔案系統的選擇，並分享了相關的開發進度與討論連結。此外，作者修復過程中所使用的 14 個自定義工具與詳細的事故分析報告，已在 GitHub 的 msedek/btrfs_fixes 專案中開源，提供給面臨類似困境的進階使用者參考。