定期的にスナップショットを作成するbtrfsボリュームがあります。スナップショットは循環され、最も古いものが1年になりました。そのため、大容量ファイルを削除しても、実際に削除してから1年間スペースが確保できない場合があります。
約1年前にパーティションを大きなドライブにコピーしましたが、以前のパーティションはそのまま残りました。
今新しいドライブが破損しているので、データを取得する唯一の方法はbtrfs-restore。私が知っている限り、新しいドライブのデータはまだ古いより小さいドライブに収まるべきであり、ファイルは実際にはあまり変わりません（最大数の新しいドライブが追加またはいくつか削除されますが、1年の価値があります）。オーバーヘッドスナップショットの数が大きすぎてはいけません。）だから、データを既存のドライブに復元することにしました。
しかし、回復されたデータは予想よりはるかに早く既存のドライブをいっぱいにしました。私はこれがbtrfsの実装に関連していると思います。
- 大きなファイルを作成します。
- ボリュームのスナップショットを作成します。両方のファイル（元のファイルとスナップショットのファイル）がロードと同じディスク範囲を参照するため、スペース使用量は変わりません。ただし、btrfsの書き込み時にコピー属性のためにこれら2つのファイルのいずれかを変更すると、スペース使用量が増えます。
- 同じ内容で大きなファイルを上書きします。 btrfsは内容が変更されていないことを認識していないため、ファイルサイズが大きくなるにつれてスペース使用量が増加すると疑われます。その結果、ファイルが占有するブロックをコピーし、最終的に同じ内容で埋められ、2つの異なるブロックセットに2つの同じファイルが生成されます。
btrfsは、「遺伝的に関連する」ファイル（つまり、ファイルをコピーするか、そのファイルがあるサブボリュームのスナップショットを撮って同じファイルから派生します）、コンテンツは同じですが、別々のブロックセットに格納されているファイルを見つけるメカニズムを提供します。 ？ ？この状況を元に戻して転送リンクに戻ってスペースを解放しますか？
ベストアンサー1
要約：これを行うことができるツールがありますが、公式ツールバーの一部ではなく、デプロイメントリポジトリにない可能性があります。さまざまなツールから選択して自分で構築する必要があるかもしれません。詳しくは下記をご覧ください。
ツール
btrfs Wikiには次の記事があります。重複排除、ここではいくつかのツールも言及されています。
より多くのツールがあります。そのうちの1つを見てみましたが、執筆時点で6年間維持されていないようで、btrfs Wikiのツールを使用することにしました。
現時点では、これらは公式btrfsファミリーの一部ではなく、少なくともUbuntu 20.04はそのパッケージを提供していません。自分でビルドする必要があります。
dduper有望に見えます。ファイルとブロックベースの重複排除を実行すると主張します（つまり、ファイル全体と2つ以上のファイル間の同じブロックを重複排除できます）。また、内部btrfsのインデックス付けに依存しているので、高速だと言われています。 Pythonで書かれているので、使用する前にビルドする必要はありません（prettytableただし、コンピュータにPythonパッケージが必要です）。しかし、4KB未満のファイルはスキップしているようです。これは、同じ小さなファイルが多い場合は非生産的だと思います。
行くことにしましたduperemove、ファイルベースの重複排除のみを実行します。 Cビルド環境と自動化ツールに加えて、libsqlite3-devコンピュータにこのパッケージが必要です。ソースコードを取得し、makeソースディレクトリから実行してビルドします。その後、システムにランダムなエントリを追加したくないduperemoveユーザーのためにソースディレクトリから直接実行できます。make install
走るduperemove
これ文書2つの実行方法が挙げられていますduperemove。直接実行するか、fdupes出力をduperemove。ただし、2〜3 TBのデータセットと約400万個のファイルの場合、2番目は非常にリソース集約的であることがわかりました（1日後の進行率は約0.5％であり、継続的なスワッピングでメモリを使用するとシステムのパフォーマンスが低下します）。ほとんど利用できません。
私に効果があるようなもの
sudo duperemove -drA /foo --hashfile=/path/to/duperemove.hashfile
これは次のことを行います。
- アカウントはディスク上のすべてのエントリにアクセスできないため、プロセス全体をrootとして実行してください。
-d単にハッシュを収集して重複リストを出力するのではなく、結果を重複排除（）します。- 与えられたパスのサブディレクトリに再帰（
-r） - 重複排除のためにファイルを読み取り専用で開きます（
-A私のスナップショットは読み取り専用であるため必要です） - ハッシュをメモリ（）の代わりにファイルに保存することには
--hashfile2つの利点があります。- ハッシュファイルがそのまま残っている限り、プロセスはいつでも中断され、後で再開される可能性があります。
fdupesハッシュファイルはディスク容量（ブロックあたり90バイト、ファイルあたり270バイト）を占めますが、プロセスはモードで実行されているのとは異なりシステムメモリを占有しません。
duperemove複数のステップで実行：
- インデックスディスクの内容（つまり、ハッシュファイルに保存されている内容）
- 冗長ハッシュをメモリにロードする
- 重複ファイルの削除
duperemove索引データベースが変更されていない限り、いつでも中断して再開できます。
試験結果
私が実行しているディスクduperemoveには8つのサブボリュームがあります。します。スナップショットを含めると、ディスクに約500万〜600万のファイルを保存でき、3.5TBを占めます（重複排除前、重複排除後約1.8TB）。
実行が開始され、進行状況が表示された場合、duperemoveパーセントは重複排除プロセス全体ではなく索引付けステップのみを表します。重複したハッシュをロードすることは、確認されたブロックの数によっては、これよりはるかに少ないか多い場合があります。重複排除には、索引付けとほぼ同じ時間がかかります。また、索引付けステップの進行状況の計算は、ブロック数ではなくファイル数のみに基づいているように見えるため、すべての大容量ファイルが最初にある傾向がある場合、必要な合計時間/空間を示す信頼できない指標となります。 （または終了）ファイルの。エピソード。
冗長データをロードすると使用可能なメモリが消費される可能性がありますが、索引付けフェーズ中にリソース使用量はハッシュファイルで作業するときにシステムの応答性を維持するのに十分なほど低くなります。索引データベースがシステムで使用可能なメモリー量を超えると、過度のスワップが発生し、システムの速度が低下する可能性があります。
すべてのエントリ（デフォルトのブロックサイズ128K）をインデックス化するのに約28日かかり、21GBのハッシュファイルが作成されました。 36日目にメモリが不足してシステムが応答しなくなり、中断しなければなりませんでした。duperemove4日間、プロセスのメモリ使用量は12〜14 GBほど変動しましたが、システムが利用できなくなるまで、合計メモリ使用量は増加し続けました。
次の試みでは、サブボリュームを1つずつ重複排除し、データが移動されたことを知っている2つのサブボリュームの部分間を再実行することにしました。私は1024Kのブロックサイズから始めましたが、より良いパフォーマンスのために、より小さな冗長ブロックとブロックサイズより小さいファイルを見逃しました。これは約24時間かかり、最終的に私のドライブに約45GBの空き容量がありました。パフォーマンスは満足ですが、予想された省スペースではありませんでした。
300Gサブボリュームで4Kを使用した別の試みを中止しました。インデックスは1024Kより約4倍かかりましたが、3日後でも重複ハッシュロードは完了しませんでした。別の64K試行は4時間で完了しました。小さなチャンクだけが重複排除されるため、最初のパス以降の後続のパスの重複排除はより早く完了する必要があります。
したがって、実際の経験に基づいて、私のアドバイスは次のようになります。
- ハッシュファイルの配置が重要です。
- 十分なディスク容量があることを確認してください（スペースがないため、中断してファイルを移動して再起動する必要がありました）。
/tmp再起動時に消去される可能性があるため、おそらく良い考えではありません（再起動する予定がない場合でも、システムのクラッシュや停電が発生しても安全です）。- ホームディレクトリを暗号化すると、私が観察したよりもパフォーマンスが低下します。私の経験では、外付けUSBディスクのパフォーマンスは内蔵HDの暗号化されたホームディレクトリよりも優れているようです。
- 複数の読み取り専用サブボリューム間でデータの重複を削除することはできません。同じサブボリュームに複数の読み取り専用スナップショットがある場合は、これらのスナップショットの1つだけ（通常は最新のスナップショットまたは最も長く保持するスナップショット）のみを確認するパスを選択します。現在のセットの一部のファイルが最新のスナップショットではなく古いスナップショットと一致しない限り、すべてのスナップショットを取得するのに時間がかかり、効率が悪くなります。
- 部分重複排除 - ファイルシステムを複数の部分に分割し、それらの間に重複したデータがたくさんないようにします。これにより、重複したハッシュをロードするときにスペースが節約されます。
- 次の説明に従って、最適なブロックサイズを決定します。duperemoveの正しいブロックサイズの選択。私のドライブの場合、16Kは0.6〜1TB（重複排除前）の部分で正しく機能していましたが、8Kでは冗長ハッシュロードが数時間から2日以上に増加しました。つまり、16Kが私が使ってきた最高のオプションです。小さな部品の場合、4Kはうまく機能します。