ブロックレベルまたはより詳細な重複排除に使用できるソリューションは何ですか?
「Copy-On-Write」アプローチを採用したファイルベースのものもあります。
ブロック レベルの「コピー オン ライト」を探しています。そうすれば、共通ブロック、またはできればファイルの一部を定期的に検索し、それらをマージして、CoW 使用方法のフラグを立てることができます。このようなものが利用できるでしょうか、それともまだ作成する必要がありますか? Btrfs の重複排除がブロック/ファイル/サブパート レベルであるかどうかはわかりません。LessFS はありますが、どのレベルの重複排除を提供するのかわかりません。他のソリューションがあるでしょうか?
答え1
ブロック レベルの重複排除に関しては、ZFS が現時点では文句なしに最高の実装だと思います。重複排除 (オンになっている場合) は読み取り/書き込み機能に直接組み込まれているため、事後最適化用に設計されていません。このため、重複排除テーブルの最も関連性の高い部分をメモリ内に保持しようとすると、負荷がかかったときにメモリを少し消費する可能性がありますが、ZFS はメモリの 50% を超える消費をしないように制限するのが得意です。これは、インストールされているメモリの量によって異なりますが、かなり恣意的に見える場合があります (2Gb の 50% と 64Gb の 50%、特にメモリを必要とするユーザー タスクがほとんどない場合)。
使用目的に応じて、いくつかのオプションがあります。
オープンインディアナSolarisをベースにした優れたデスクトップおよびサーバーオプションがあるようです
FreeBSD（9.0以降）には、ZFSのかなり高度なバージョン（重複排除機能を含む）が組み込まれています。注目すべきFreeBSD（当時はMonoWall）派生ディストリビューションの1つは、NAS4無料これにより、NAS の作成が非常に簡単になります。
Linuxにはいくつかのオプションがあり、重複排除機能付きのものもあれば、そうでないものもあります。重複排除機能をお探しなら、私が見た中で最も注目すべきものは次のとおりです。翻訳元彼らの進捗状況やプロジェクトがどの程度安定しているかはわかりませんが、間違いなく有望に見えます。
部分的なブロック重複排除機能に関しては、これまで、それが可能であると報告しているものを何も見たことがありません。
答え2
あなたの質問は、「ブロック」という用語のせいで少し混乱しています。この用語は、ディスクやファイルシステムに関して非常に多用される言葉です。(しかし、あなたの周囲の文脈が理解を助けてくれます。) Btrfs は固定サイズのファイルシステム「ブロック」を扱うのではなく、可変サイズの「エクステント」を扱います。(ただし、混乱を招くように、可変サイズのブロック ゾーンも定義しています。) ZFS は、部分的にまたは主に、ファイルシステム「ブロック」を扱います。これは、そうすることで、解決する問題が大幅に容易になるためです。Btrfs と ZFS はどちらも、それ自体が抽象化されたディスク レベルの「ブロック」を認識します。(さらに、「ブロック レベルのストレージ」もありますが、これは意味的に異なる可能性があります。) これらの説明は少し間違っていたり、十分に明確でなかったり、100% 正確ではなかったりするかもしれません。 (ブロックのトピックについて明確さと 100% の正確さが必要な場合は、読んでいないことにしてください。続行するために大まかな理解だけが必要な場合は、そのまま進んでください。) この回答の主なポイントは、「ブロック」を完璧に定義することではなく、以下の議論であり、これは私の得意分野です。
@killermist が書いたように、ZFS は [ZFS] ブロックレベルの重複排除をネイティブにサポートしています。
ZFS では、既定では有効になっていません。十分なメモリがない状態で有効にすると、パフォーマンスに多大な影響が出ます。また、逸話的に、ZFS では、ハッシュテーブル全体を RAM に収めるために、推奨される「1 TB のストレージあたり 1 GB の RAM」よりもかなり多くの RAM が必要です。しかし、それでも、ハードウェアによっては、40 MB/秒以上の書き込み速度を実現できます。2008 年頃のテクノロジで 2015 年頃のドライブを実行している場合は、この速度を実現できます。主にアーカイブ データの場合、私にとってはまったく問題ありません。ZFS の重複排除の最大の欠点は、重複排除をオンにして、すべてを同じファイル システム上の新しい一時ディレクトリにコピーし、元のファイルを削除してから、(重複排除された) 一時コンテンツを戻す以外に、「バッチ/オフライン」(より正確には「アウトオブバンド」) モードでそれを実行するエレガントな方法がまだないことです。 (ただし、古いファイルの削除には、最初のコピー/重複排除操作よりも時間がかかる可能性があります。) 通常私が行うことは、基本的なレイアウトを変更するためにアレイを定期的に再設計する必要があるまで待ってから、重複排除をオンにして古いアレイから新しいアレイにコピーすることです。
Btrfs の重複排除は、おそらく少し不確実で、現在この作業を実行できるのはサードパーティのユーティリティだけです。(ただし、十分にサポートされているカーネル API または cp の十分にサポートされているオプションのいずれかを使用し、いずれにしても重複を判断するための独自のロジックが必要であり、これが正確であることが期待されます。) ただし、1 つの潜在的な利点は、これらのユーティリティが「帯域外」であることです。ただし、ほとんどのユーティリティの欠点は、処理中にパフォーマンスが低下することです。処理が完了するまでに数時間、数日、場合によっては数週間かかることがあります。(個人的には、1 年に 1 回、HDD を数日間処理するよりも、常に遅い書き込みパフォーマンスの帯域内 ZFS 重複排除に対処する方がましです。)
私が知っている2つのBtrfsソリューションは、ファイルではなく「ブロック」（ただし、定義は異なります）を扱います。ミツバチ、 そして重複。
たとえば、Bees は、使用可能なメモリとその他の要因に基づいて、最初の実行時に「ブロック」サイズを任意に定義します。(私は使用していないため、その目的、機能、メカニズム、長所/短所について誤解している可能性がありますが、最近オプションとして評価しただけです。)
Bees は、継続的に実行され、ディスクをそれほど激しく叩かないように設計されているため、ややハイブリッド的であると言えますが、技術的には ZFS の重複排除のような「インバンド」ではありません。事後に重複を拾い上げて、軽く重複排除を試みるだけです。任意に定義されたブロック サイズで動作することは、設計上、ハッシュ テーブルが RAM に収まることを意味します。欠点は (おそらく)、「ブロック」内に同じエクステントが存在する可能性があるものの、それらが存在する「ブロック」がそれ以外は異なるため、Bees が重複排除を実行できない可能性があることです。
「ファイル」レベルのBtrfs重複排除を特に実行するユーティリティ（ベッドアップ、デュペレムーブ、リント、その他）でも要件を満たす可能性があります。確信はありませんが、そうであるように思われます。なぜなら、「cp --reflink=always」コマンドでも実際には「ファイル」の重複排除は行われないからです。これは Btrfs の重複排除です。範囲参照リンクされた「ファイル」が変更されると、Btrfs は変更された範囲のみを、独自の一意の範囲に重複排除解除します。ファイルの残りの部分は重複排除されたままです。そのため、重複排除された大きなファイルは、独自の一意のファイルであるかのように分岐しますが、大部分は依然として重複排除されています。
（これはまた、「ファイル」がreflinkされているかどうかを判断するのが非常に難しい理由でもあります。なぜなら、その概念は実際には意味をなさないからです。ファイルの範囲それ自体が他の同じエクステントに参照リンクされている可能性があります。この概念は理にかなっています。しかし、偶然にも、これは特に答えるのが難しい質問です。そのため、Btrfs 重複排除ユーティリティが重複排除済みのものを追跡しない限り、ファイルが重複排除済みかどうかを「検出」しようとする努力は無駄です。検査する refcount のような属性はありません。とにかく、もう一度重複排除する方が簡単です。対照的に、ファイル全体が従来の方法でハードリンクされているかどうかを判断するのは簡単です。特定の inode の st_nlink カウントを確認するだけです。
「ファイル全体のクローン」がないことは、実際には「フリー」スナップショットや重複排除をサポートするすべての CoW ファイルシステムの本質的な機能であり、Btrfs エクステント、ZFS ブロック、またはその他のものを扱う場合でも当てはまります。そのため、どちらかがおそらく質問の答えになります。(私が知っている限り、これらすべてを実行できる、または実行できるように計画されている CoW ファイルシステムは他に少なくとも 3 つあります。nilfs2、bcachefs、xfs です。)
これについては触れていませんが、私の知る限り、重複排除技術はファイルタイプを認識しません。言い換えれば、重複排除技術は *.jpg メタデータをスキップして、重複排除に圧縮されたイメージ データのみを考慮することを知りません。同様に、重複排除技術のいずれもファイル マジック ナンバーを考慮しません (少なくとも重複排除に考慮する内容を決定するために)。これはキラー機能になる可能性がありますが、定義の継続的な更新が確実に必要になります。また、ファイルをエクステント、ブロックなどの抽象的な M:M コレクションとして扱う場合、設計が非常に難しくなる可能性があります。