如果您打开以下defragment
部分btrfs-filesystem(8)
,你会看到开发者留下的以下不祥的铭文:
警告:使用 Linux 内核版本 < 3.9 或 ≥ 3.14-rc2 以及 Linux 稳定内核版本 ≥ 3.10.31、≥ 3.12.12 或 ≥ 3.13.4 进行碎片整理将破坏 COW 数据的引用链接(例如使用
cp --reflink
、快照或重复数据删除)。这可能会导致空间使用量显着增加,具体取决于断开的引用链接。
听起来很糟糕。它的一个卖点btrfs
是它能够创建快照而无需复制所有内容。我主要创建只读快照。
只读快照的文件是否也算作“COW 数据”,或者父子卷重复数据删除是否会在不导致磁盘空间膨胀的情况下继续存在?
答案1
Btrfs 碎片整理不会破坏全部转发链接
只是您指出的特定实例。因此,如果您有 subvolumeA
以及该 subvolume 的S1
快照,则运行 defragS2
A
只是子卷A
将中断它与快照之间的重新链接,但S1
仍将S2
共享它们最初彼此之间的任何数据。如果您随后拍摄 的第三个快照A
,它将与 共享数据A
,但不会与S1
或共享数据S2
(因为A
不再与S1
或共享数据S2
)。
鉴于这种行为,在谈论持久快照时,您会依次遇到三种潜在情况:
- 你关心的最小化空间使用过,但不太担心性能。
在这种情况下,唯一的选择是根本不运行碎片整理。 - 你关心的表现,但不是空间使用情况。在这种情况下,对所有内容进行碎片整理。
- 您关心空间使用和性能。在这个均衡在这种情况下,我个人建议仅对源子卷进行碎片整理(因此仅对
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
答案2
是的,只读快照中的文件算作 COW 数据,并且会因碎片整理而导致磁盘空间膨胀。
当进行碎片整理时,数据会从旧的盘区复制到较少的新盘区中。新范围与旧范围不同。文件的所有其他副本(例如快照中)仍然指向旧范围。因此,你会遇到数据膨胀的情况。
邮件列表上有一个很长的关于碎片整理的帖子这里其中有一些有趣的点。