btrfs —読み取り専用のスナップショットを持つサブボリュームをデフラグすることは危険ですか？
btrfs-filesystem(8) のdefragmentセクションを開くと、開発者が残した次の不吉な碑文が表示されます。
警告：Linuxカーネルバージョン<3.9または≥3.14-rc2、およびLinux安定カーネルバージョン≥3.10.31、≥3.12.12または≥3.13.4は、COWデータの参照リンクを分割します（たとえば、
cp --reflink、スナップショット、または重複除外されたデータ）。これにより、分割された参照リンクによっては、スペース使用量が大幅に増加する可能性があります。
ひどいですね。 btrfsのセールスポイントは、すべてをコピーせずにスナップショットを作成できることです。私は主に読み取り専用のスナップショットを作成します。
読み取り専用のスナップショットのファイルも「COWデータ」としてカウントされますか、それともディスク容量を増大させずに親サブボリュームの重複排除が存続しますか？
はい、読み取り専用のスナップショット内のファイルはCOWデータとしてカウントされ、デフラグによるディスク領域の肥大化の一因になります。
最適化が行われると、データは古いエクステントから少数の新しいエクステントにコピーされます。新しいエクステントは、古いエクステントとは異なります。 （スナップショットなどの）ファイルの他のすべてのコピーは、依然として古いエクステントを指しています。したがって、データの膨張があります。
here から始まるメーリングリストのデフラグに関する長いスレッドがありますが、いくつか興味深い点があります。
Btrfsデフラグはallreflinksを壊しません
指し示す特定のインスタンスのみ。したがって、サブボリュームAがあり、そのサブボリュームAのスナップショットS1とS2がある場合は、justサブボリュームAは、それとスナップショット間の参照リンクを解除しますが、S1とS2は、元々あったデータを相互に共有します。次に、Aの3番目のスナップショットを取得すると、Aとデータを共有しますが、S1またはS2とは共有しません（AはS1またはS2）とデータを共有しなくなりました。
この振る舞いを考えると、永続的なスナップショットについて話す場合、次の3つの潜在的なケースがあります。
- あなたは使用されるスペースを最小化することに関心がありますが、パフォーマンスについてはそれほど心配していません。
この場合、唯一のオプションは、デフラグをまったく実行しないことです。 - performanceを気にしますが、スペースの使用量は気にしません。この場合、すべてを最適化します。
- スペースの使用量とパフォーマンスの両方を気にします。このbalancedの場合、個人的にはソースサブボリュームのみ（上記の説明ではサブボリューム
Aのみ）をデフラグして、スナップショットのローテーションと一致するスケジュールで。アイデアは、スナップショットを撮る直前に、スペースの使用量とパフォーマンスのバランスがとれる頻度でdefragmentすることです。原則として、この方法をとる場合は、毎日または毎週のスナップショットを実行している場合は毎月、またはそうでない場合は4つおきのスナップショットを実行してデフラグを実行し、それが影響に基づいて間隔を調整しますスペース使用量。
出典： Btrfs mailinglist 、Spacedogによる参照。
Btrfsデフラグ読み取り専用スナップショット
私の試行錯誤の経験から、（新しいzstd圧縮を使用するために）btrfsでスナップショットを最適化すると、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/