btrfs — 對具有隻讀快照的子捲進行碎片整理是否危險？

如果您打開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 數據”，或者父子卷重複數據刪除能否在不導致磁碟空間膨脹的情況下繼續存在？

是的，只讀快照中的文件算作 COW 數據，並且會導致碎片整理導致的磁碟空間膨脹。

進行碎片整理時，數據會從舊數據塊複製到更少的新數據塊中。新範圍與舊範圍不同。該文件的所有其他副本（例如，在快照中）仍指向舊擴展區。因此，您有數據膨脹。

從這裡開始的郵件列表上有一個關於碎片整理的長執行緒，其中有一些有趣的點。

Btrfs 碎片整理不會破壞所有的重新連結

只是您指向的特定實例。因此，如果您有 subvolume和該 subvolume 的A快照，則僅在subvolume上執行 defrag將破壞它與快照之間的重新連結，但仍將彼此共享它們最初的任何數據。如果您隨後拍攝 的第三個快照，它將與 共享數據，但不與or共享數據（因為不再與or共享數據）。S1``S2``A``A``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

引用自：https://unix.stackexchange.com/questions/400225