我有几个运行 Debian 8、dovecot 和 btrfs 的机器。我使用 btrfs 快照进行短期备份。为此，我保留了 14 个邮件子卷快照。
性能还行，直到删除快照时才恢复正常：一旦 btrfs-cleaner 启动，一切几乎都停止了。这会导致 drbd 由于超时而失去与辅助节点的连接。这种情况在多个机器上都发生过，因此不太可能是硬件相关的问题。
Spike 是删除快照的地方：
我无法相信这是正常行为。所以我的问题是：有没有人遇到过这个问题，知道如何解决或调试它，或者作为最后的手段，如何通过不同的方式避免它？
系统为 Dell R710、Debian 8、内核 3.16，挂载选项：rw、noatime、nossd、space_cache
编辑：更多系统信息
双 R710、24GB RAM、带写入缓存的 H700、8x1TB 7.2k Sata 磁盘（作为 RAID6）、DRBD 协议 B、用于 DRBD 的专用 1Gb/s 链路
编辑：通过 rm -rf 删除快照内容。限制 IO，否则它会像 btrfs-cleaner 一样失控：
我认为从 io 角度来看，这要糟糕得多。唯一的优点是我可以控制用户空间 rm 的 IO 负载。
另一处编辑：Iops massacree
答案1
在 CoW 世界中（基本上是 BTRFS 和 ZFS），删除快照/子卷需要执行许多“繁重”的元数据操作，这意味着多次寻道。这是因为文件系统解析自己的结构以确定有问题的快照专门使用的块。这反过来会使系统陷入瘫痪。
要确认这是问题所在，请执行以下操作：
- 打开两个终端
screen - 在第一个终端上，运行
iostat -x -k 1 - 在第二个终端上，删除快照
- 在删除过程中，检查第一个终端：您可能会发现磁盘占用率为 100％，正在读取许多小数据块。
如果问题得到确认，您可以尝试第一的删除快照内容（使用简单的rm），然后删除快照本身。
附注：虽然 CoW 文件系统非常灵活，但它们的设计并非纯粹为了性能。虽然 ZFS 仍然相当快，但对于 BTRFS 来说，情况并非如此。
无论如何，对于 ZFS 来说，大型子卷的删除也是有问题的（直到它实现了后台运行的删除过程......）
答案2
它看起来像btrfs 配额功能中鲜为人知的漏洞。
只需通过下一个命令禁用 btrfs 配额。
btrfs quota disable /
UPD：我发现了详细的问题分析。这不是一个错误，而是一个功能。