btrfs - 読み取り専用スナップショットでサブボリュームの最適化を実行するのは危険ですか？

Btrfs の最適化は中断されません。みんなフォワードリンク

あなたが指摘した特定のケースです。したがって、サブボリュームAとそのサブボリュームのスナップショットがある場合は、S1デフラグを実行してください。S2AただサブボリュームはAそのボリュームとスナップショットの間の再接続を失いますが、元々持っていたデータは引き続きS1共有S2されます。 3回目のスナップショットを撮ると、Aデータは共有されますが、共有されませAん（データが共有されなくなったため）。S1S2AS1S2

これらの動作を考慮すると、永続的なスナップショットについて話すときには、次の3つの潜在的なシナリオがあります。

1. あなたは心配スペースを最小限に抑える使用しましたが、パフォーマンスはあまり心配しませんでした。
   この場合、唯一のオプションはデフラグをまったく実行しないでください。。
2. あなたは心配パフォーマンスしかし、スペース使用量ではありません。この場合、すべてをデフラグ。
3. スペース使用量とパフォーマンスに興味があります。これにバランスの取れたこの場合、個人的にはソースサブボリューム（A上記ではサブボリュームのみ）に対してのみデフラグを実行し、スナップショット循環に一致するスケジュールに従ってデフラグを実行することをお勧めします。アイデアは、defragmentスナップショットを実行する前に、スペース使用量とパフォーマンスの間の適切なバランスを提供する頻度でスナップショットを撮ることです。通常、このアプローチを使用する場合は、毎日または毎週スナップショットを実行する場合は、最初に月に一度デフラグを実行し、そうでない場合は、4番目のスナップショットごとにデフラグを実行し、それが影響を受ける程度にに従って時間間隔を調整します。空間の活用。

源泉：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に低下しました。