btrfs 翻车记

7
6
2023

本文来自依云's Blog，转载请注明。

如标题所言，我用了多年的 btrfs，终于还是遇到翻车啦。由于文件系统翻车了，相关日志内容缺失，所以本文我仅凭记忆描述事件，就不提供准确的日志输出了。

事件经过

出事的是 archlinuxcn 的编译机。那天中午时分我就收到了 Grafana 给我发送的莫名其妙的报警邮件，称某个监控项无数据了。我去面板上瞅了半天，明明有数据的啊。不解，但是忙别的事情去了，也没有细究。晚些时候，我又收到了好些同类告警，遂登录机器打算检查 Grafana 日志。但操作过程中，退出 zsh 的时候我好像看到了写命令历史时出现「read-only filesystem」的字样？于是检查了一下，发生大事不好了，文件系统真变只读了！

这个 btrfs 是我上次迁移机器的时候换上的，因为我觉得过了这么多年，btrfs 挺稳定了啊，而定时快照很方便，devtools 也支持通过快照来快速创建打包用的 rootfs（虽然大部分时候都在 tmpfs 上打包了用不上）。但我们编译机一直以来有个问题：硬盘有多少用多少。前一任编译机用的 1T 硬盘，是刚刚够用，现在换 2T 了，结果用着用着又只剩下200多GiB啦……肥猫最近开始玩 bees 去重了，听说在其它机器上效果显著。不过这台编译机快照多，这「蜂群」嗡嗡了几天都没完事，还出事了。

btrfs filesystem usage 一看就发现，空闲200多G数据是真的（因此没有触发相关报警），但是元数据满了，也没有未分配空间了。这种事群里有多位群友遇到过了，问题不大，加个设备再 balance 一下就好了。我一开始是这么想的，刚好有两个挺大的 swap 分区能够用来腾挪。结果 btrfs 告诉我，文件系统只读，添加设备失败！那好，我 remount rw 一下。结果 btrfs 说文件系统出毛病了，不支持 remount rw！

这个时候我才感觉事情有点难办了。这个 btrfs 文件系统是 /，并不能卸载啊。没有找到在线修理的办法，只好呼叫凤凰卷，通过 iDRAC 进入 archiso。期间服务器重启了一次，但连过去依旧是只读的。进到 archiso 之后，尝试抢在报错之前添加设备，但是并没有成功。会卡住一会儿，然后报错「No space left on device」。按 farseerfc 的建议，clear_cache 和 zero-log 都试过了，但并没有解决问题。有人建议把大文件 truncate 一下，看看能不能刚好释放出 1G 的连续空间出来，但是我有定时快照呀，truncate 了也不会立即释放空间。最后卷直接下单了新机器，开始 btrfs send……

事后

服务器迁移还比较顺利。数据接收完毕，网络配置更新一下，引导器装好，重启，熟悉的编译机就回来啦～除了 nvchecker 好像跑得有点慢？怎么 ping Google 要 60ms 的？原来是忘记更新 /etc/resolv.conf 了，里边还写着旧 ISP 的 DNS 服务器地址呢。systemd-resolved 这次做了回好事，把 DNS 服务 fallback 到了 9.9.9.9。DNS 解析慢是 fallback 过程造成的，而 ping Google 延迟高，是因为 9.9.9.9 不知道怎么回事，给解析到比较远的地方去了。

新编译机 CPU 比之前那台快了不少，硬盘也增加到了 3.4T。挺好的，除了这时机不太好，旧编译机还有近一个月到期……另外由于是突发状况，所以没有及时缩短 DNS TTL，导致迁移完成之后 DNS 解析没有及时跟上（隔天我陆陆续续从另一台使用这台编译机转发邮件的机器那里收到了好些邮件，都是抱怨这编译机连不上的）。

蜂群(bees)也重新开始工作了。这次快照较少，我还专门为了它们暂停过自动快照，过了一段时间之后首次扫描终于完成了。之后它们就能很快跟上进度，不会消耗大量 CPU 了。

我添加了定时任务来执行 btrfs balance start -dusage=10 /，每周释放一些使用率低的数据块组，避免空间分配了又不怎么用，到最后明明有剩余空间却让元数据无处可写。

farseerfc 对出事的 btrfs 进行了更多不同方案的修复尝试，但依然未能修好。

一些抱怨

没想到我用了这么多年的 btrfs，还是被坑到了。明明还有不少空闲空间，但是 btrfs 不知道用。我看到最近有个「automatic block group reclaim」特性，支持自动回收块组了，但是搜索结果第一项结果是今年年初有人在邮件列表上报告说它有问题……出现问题 ro 挺好的，但是这个状态下不让进行维护操作就太难受了。作为 / 文件系统使用时，对于远程机器来说，即使有 iDRAC 或者 IPMI 之类的东西，用起来也费事，还不得不中断可能还活着的服务。而对于不支持远程访问的机器就更麻烦了，比如在家办公时办公室的机器，或者出差旅游探亲时在家的机器。我也考虑过在 initramfs 里配网络、开 sshd，但是并没有现成的工具，事发时再配的话，一次性成功的可能性太低了。

至于事发原因，蜂群(bees)只是加快了元数据空间的使用（dedupe 快照的结果），其本身并没有问题。出事重启之后，在再次被挂载为只读之前，还是写入了不少数据，包括一次成功的快照（后来查 pacman 数据库损坏的问题时发现的）。这可能是后续添加设备都无法成功的原因。

以前用的 ext4，在文件系统快满时只是碎片化严重、效率降低，它甚至还会给 root 保留一部分空间来处理问题。后来用 zfs，快满了就 0B/s，等于废掉。现在 btrfs 遇到空间不足也没有好太多，变只读了。（我还打算抱怨一下新文件系统可靠性不如旧的来着，想想前不久在群里看到 btrfs 抓到了位反转，还是不抱怨了。大家各有千秋。）

2023年07月08日更新：farseerfc 把它救活了！核心方法是把这里的 global reserve 大小由 512M 改成 2G。因为之前重启了一次，那时不仅成功创建了一个新快照，还删掉了一个旧的。然后它删着删着就把 512M 的 global reserve 给用完了，就报错、事务回滚，于是就过不去了。和邮件列表上这个问题是一样的：Global reserve and ENOSPC while deleting snapshots on 5.0.9 — Linux BTRFS。

2023年07月25日更新：其实本文所述内容是罕见情况啦，并没有多少人会遇到的，大家不用害怕。另外新写了一篇《btrfs 元数据满了怎么办》，记录大多数人遇到的元数据满的问题如何解决。

Category: Linux | Tags: linux btrfs | Read Count: 10302