Btrfs 文件系统修复技巧-服务器评测

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

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 的下载地址：请点这里

本文永久更新链接地址：http://www.linuxidc.com/Linux/2015-05/117257.htm

Btrfs 文件系统修复技巧