这个btrfs快照移除性能是否正常？
我有几个盒子运行Debian 8，dovecot和btrfs。 我正在使用btrfs快照进行短期备份。 为此，我保留了邮件子卷的14个快照。
在删除快照之前，性能还是可以的：只要btrfs-cleaner启动，所有事情都快要停止了。 这会由于超时而失去与辅助节点的连接。 这发生在几个盒子，所以这不太可能是一个硬件相关的问题。
Spike是快照删除的地方： 
我不敢相信这是正常的行为。 所以我的问题是：有没有人有这个问题的经验，有关如何解决或debugging它的任何想法，或作为最后的手段如何通过做不同的事情来避免它？
- ext3 / 4上的不可变硬链接？
- 开放源代码备份系统与用户驱动的恢复
- 检查孤立的快照 – ESXi5
- 无法恢复快照：“本机中处理器的供应商是不一样的”
- libvirt和qemu / kvm -snapshot选项
系统是戴尔R710，Debian 8，内核3.16，安装选项：rw，noatime，nossd，space_cache
编辑：更多系统信息
双R710,24GB RAM，H700带写caching，8x1TB 7.2k SATA磁盘作为RAID6，DRBD协议B，DRBD专用1Gb / s链路
编辑：通过rm -rf删除快照内容。 对IO进行限制，否则就会像btrfs-cleaner那样跑掉：
我会得出这样的结论，万一是更糟糕的。 唯一的好处是我可以控制用户空间的IO负载。
另一个编辑：IOP大屠杀
在CoW世界（BTRFS和ZFS，基本上），删除快照/子卷需要许多“重”元数据操作，这意味着许多头部search。 这是由于文件系统parsing自己的结构，以确定违规的快照专用的块。 这反过来又可以使系统屈膝。
要确认这是问题，请执行以下操作：
- 用
screen打开两个terminal - 在第一个terminal上运行
iostat -x -k 1 - 在第二个terminal上，删除快照
- 在删除期间，检查第一个terminal：您可能会发现您的磁盘占用率高达100％，读取的数据块很多。
如果问题得到确认，您可以尝试先删除快照内容（使用简单的rm ）， 然后删除快照本身。
作为一个侧面说明：虽然CoW文件系统是非常灵活的，但它们不是为了纯粹的性能而devise的。 虽然ZFS保持相当快， 但BTRFS不能说同样的事情。
无论如何，大的子卷删除也是ZFS的问题（直到它实施了后台运行的删除过程…）