Btrfs 文件系統工具隨著內核版本的進步在逐步成熟，不過難免在使用過程有會有一些意外發生，遇到無法掛載的情況怎麼辦？
若是在其他文件系統異常的情況下，第一反應當然是 fsck 系列工具咯～不過若是在終端運行它的話，會得到這樣的結果：
btrfs check 子命令慢！在撞牆或果斷調用 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 scrub 時提示大量錯誤，而且又是單盤環境當你挽救了重要數據之後，最後又回到 btrfs check 這裡了，它會嘗試修復文件系統。注意為了避免誤操作，僅在加上 --repair 選項時才真正執行修復。
個人覺得，若是重要數據不多的話，離線恢復不難的話，還不如重新格式化得了……
Btrfs 文件系統本身健壯性還是不錯的，不過由於工具集還在發展，偶爾出些小狀況，通過上述的修復手段也都能應對。
此外，提醒下若是突然遇到掛載異常又排出了硬件問題，可以到 IRC 頻道或者 Wiki 的頁面看看是不是最近工具集導致的，有時可以節省不少繞彎的精力。
文中所述命令的詳情可以通過 man -k btrfs 查閱
參考資料：
怎麼把Fedora 21 Workstation Cinnamon 的桌面環境安裝到 Btrfs 文件系統的計算機上 http://www.linuxidc.com/Linux/2014-12/110844.htm
Linux文件系統Btrfs的Makefile分析 http://www.linuxidc.com/Linux/2012-10/73301.htm
Linux 文件系統Btrfs 的Kconfig分析 http://www.linuxidc.com/Linux/2012-10/73300.htm
Btrfs文件系統在CentOS中的應用 http://www.linuxidc.com/Linux/2012-08/68098.htm
Btrfs 的詳細介紹：請點這裡
Btrfs 的下載地址：請點這裡
