Btrfs 檔案系統修復技巧

2020-06-16 18:00:38

Btrfs 檔案系統工具隨著核心版本的進步在逐步成熟，不過難免在使用過程有會有一些意外發生，遇到無法掛載的情況怎麼辦？

若是在其他檔案系統異常的情況下，第一反應當然是 fsck 系列工具咯～不過若是在終端執行它的話，會得到這樣的結果：

慢！在撞牆或果斷呼叫 btrfs check 之前，請注意 btrfs 檔案系統不像其他檔案系統，大多數情況下是不需要 fsck 的，這個不幹活的 fsck 其實是為了相容在 fstab 中錯誤的非0 fs_passno 設定而生的。

再慢！btrfs check 是個猛藥，草率使用可能會適得其反。那麼接下來應該怎麼辦？

Btrfs 在磁碟上的檔案系統格式已經穩定下來了，但是各種核心態和使用者態的工具還在發展。不少錯誤或問題可以通過使用包含修復的新核心解決。

假設您已經通過無論何種方式引導了包含最新核心的 Live 環境，那麼此時可以首先嘗試以 recovery,ro 選項掛載 btrfs 檔案。

之後觀察下 dmesg 或 journalctl -k 的輸出，有沒有 btrfs 相關的 kernel oops。

沒有什麼異常的話，可以先檢查下最後存取的檔案什麼的，看是否存在。由於 Btrfs 的 COW 機制，大部分情況應該是都在的。

若有且僅有 kernel oops 的情況下，使用 btrfs-zero-log 去嘗試修復下。

若是上一步通過唯讀掛載正常且又沒有 kernel oops，那麼就可以嘗試正常的讀寫掛載了。

運氣好的話，沒什麼問題，可能意味著之前遇到的掛載異常問題已經在新的核心中修復了。但儘管如此，依然推荐執行 btrfs scrub start 命令，開始檢查全部檔案及其校驗和。

btrfs scrub 是一個在後台執行的命令，耗時比較長，在下一個普通的 Seagate 500G SATA3 7200rpm 的硬碟完成這個工作需要約 26 分鐘。期間可以隨時使用 btrfs scrub status 檢視進度。

請注意對於非 RAID 環境來講，btrfs scrub僅能檢查出檔案錯誤但無法修復問題（木有未損壞的檔案拷貝啊……），對於 RAID 1 等級別，這個過程也可以自動使用來自冗餘盤的資訊進行修復，除非加上 -r引數。

只有下列兩種情況需要執行 btrfs rescue 命令，因為它掃描磁碟檔案簇的方式真的非常費時，不過相對應的，它不要求分割區掛載：

當你挽救了重要資料之後，最後又回到 btrfs check 這裡了，它會嘗試修復檔案系統。注意為了避免誤操作，僅在加上 --repair 選項時才真正執行修復。

個人覺得，若是重要資料不多的話，離線恢復不難的話，還不如重新格式化得了……

Btrfs 檔案系統本身健壯性還是不錯的，不過由於工具集還在發展，偶爾出些小狀況，通過上述的修復手段也都能應對。

此外，提醒下若是突然遇到掛載異常又排出了硬體問題，可以到 IRC 頻道或者 Wiki 的頁面看看是不是最近工具集導致的，有時可以節省不少繞彎的精力。

文中所述命令的詳情可以通過 man -k btrfs 查閱

參考資料：

怎麼把Fedora 21 Workstation Cinnamon 的桌面環境安裝到 Btrfs 檔案系統的計算機上 http://www.linuxidc.com/Linux/2014-12/110844.htm