btrfs — 对具有只读快照的子卷进行碎片整理是否危险？

Question

如果您打开 的defragment部分btrfs-filesystem(8)，您将看到以下开发人员留下的不祥铭文：

警告：使用 Linux 内核版本 < 3.9 或 ? 3.14-rc2 以及 Linux 稳定内核版本？3.10.31，？3.12.12 还是？3.13.4 将打破 COW 数据的 ref-links（例如使用 复制的文件cp --reflink、快照或去重数据）。根据断开的引用链接，这可能会导致空间使用量的显着增加。

这听起来很可怕。一个卖点btrfs是它能够在不复制所有内容的情况下创建快照。我主要创建只读快照。

只读快照的文件是否也算作“COW-data”，或者父子卷重复数据删除会在不使磁盘空间膨胀的情况下继续存在吗？

Answer 1

Btrfs 碎片整理不会破坏所有的reflinks

只是您指向它的特定实例。所以，如果你有子卷A和快照S1以及S2该子体积A，然后运行磁盘碎片整理上刚子卷A将打破它和快照之间的reflinks，但S1并S2仍将分享他们彼此最初的任何数据。如果您随后拍摄 的第三个快照A，它将与 共享数据A，但不会与S1或S2（因为A不再与S1或共享数据S2）。

鉴于这种行为，在谈论持久快照时，您又会遇到三种潜在情况：

1. 您关心尽量减少使用的空间，但并不担心性能。
   在这种情况下，唯一的选择是根本不运行碎片整理。
2. 您关心性能，但不关心空间使用情况。在这种情况下，对所有内容进行碎片整理。
3. 您关心空间使用和性能。在这种平衡的情况下，我个人建议仅对源子卷进行碎片整理（因此A在上述解释中仅对子卷进行碎片整理），并按照与快照轮换一致的时间表进行碎片整理。这个想法是defragment在您拍摄快照之前，并且在空间使用和性能之间提供良好平衡的频率。作为一般规则，如果您采用这条路线，如果您正在执行每日或每周快照，则首先每月进行一次碎片整理，如果不是，则每四个快照进行一次，然后根据这对您的影响来调整间隔空间使用。

来源：Btrfs 邮件列表，由 Spacedog 引用。

Btrfs 碎片整理只读快照

根据我的反复试验经验，btrfs 碎片整理快照（使用新的 zstd 压缩）导致 100% 独占和 0.00 字节的共享数据。

之前btrfs defragment：

# btrfs filesystem du -s /mnt/btrfs/Backups.backupdb/d2/readonly-snapshot/
     Total   Exclusive  Set shared  Filename
   1.41GiB     6.27MiB     1.41GiB  /mnt/btrfs/Backups.backupdb/d2/readonly-snapshot/

之后btrfs defragment：

# btrfs filesystem du -s /mnt/btrfs/Backups.backupdb/d2/readonly-snapshot/
     Total   Exclusive  Set shared  Filename
   1.42GiB     1.42GiB       0.00B  /mnt/btrfs/Backups.backupdb/d2/readonly-snapshot/

共享数据降至 0.00B

Answer 2

是的，只读快照中的文件计为 COW 数据，并且会导致碎片整理导致的磁盘空间膨胀。

当碎片整理发生时，数据从旧区复制到较少的新区。新盘区与旧盘区不同。文件的所有其他副本（例如，在快照中）仍指向旧范围。因此，您有数据膨胀。

从这里开始的邮件列表上有很长的关于碎片整理的帖子，其中有一些有趣的观点。