あなたの質問は、「ブロック」という用語のために少し混乱します。これは、ディスクやファイルシステムに関して非常に過負荷の言葉です。（しかし、周囲のコンテキストは明確にするのに役立ちます。）Btrfsは固定サイズのファイルシステム「ブロック」を処理せず、可変サイズの「エクステント」を処理します。（紛らわしいことに、可変サイズのブロックゾーンも定義します。）ZFSはファイルシステムの「ブロック」を扱います。BtrfsとZFSはどちらもディスクレベルの「ブロック」を認識しています。これらはそれ自体が抽象化です。（次に、「ブロックレベルのストレージ」もあり、意味的に異なる意味になる場合があります。）これらの説明が少しずれているか、十分に明確でないか、100％正確でない可能性があります。（ブロックのトピックについて明確さと100％の正確さが必要な場合は、読んでいないふりをしてください。続行するために大まかな理解が必要な場合は、次に進んでください。）この回答の主なポイントは、「ブロック」を完全に定義することではなく、以下の説明です。
@killermistが書いたように、ZFSは[ZFS]ブロックレベルの重複排除をネイティブでサポートしています。
ZFSではデフォルトで有効になっていません。十分なメモリなしでオンにすると、パフォーマンスに多大な影響が及びます。また、ZFSでは、ハッシュテーブル全体をRAMに収めるために、「1 TBのストレージあたり1 GBのRAM」の経験則よりもかなり多くの量が必要です。しかし、それでも、ハードウェアによっては、40 MB / s以上の書き込み速度を得ることができます。私はそれを2008年の時代の技術で〜2015年のドライブで動かしています。主にアーカイブデータについては、完全に受け入れられます。ZFS重複排除の最大の欠点は、重複排除をオンにしてすべてをコピーする以外に、「バッチ/オフライン」（またはより正確には「帯域外」）モードでこれを行うための洗練された方法がまだないことです。同じファイルシステム上の新しい一時ディレクトリ、元のファイルを削除してから、（現在重複排除されている）一時コンテンツを元に戻します。
Btrfs重複排除は間違いなく少しおおざっぱですが、現在この作業に使用できるのはサードパーティのユーティリティのみです。（しかし、十分にサポートされているカーネルAPIやcpへの十分にサポートされているオプションのいずれかを使用します。どちらの方法でも、重複を決定するために独自のロジックを必要としますが、正確であることが望まれます。 「アウトオブバンド」です。ただし、ほとんどのユーティリティにかかるコストは、ハンマーで叩くとパフォーマンスが低下することです。完了するまでに数時間、数日、さらには数週間かかることがあります。（個人的には、インバンドZFS重複排除の書き込みパフォーマンスを常に遅くすることに対処します。たとえば、HDDを何日もハンマーで叩くよりも、年に1回は終了します。）
私が認識している2つのBtrfsソリューションは、ファイルではなく「ブロック」（ただし別の定義では）を処理するもので、蜂とdduperです。
たとえば、ミツバチは、利用可能なメモリやその他の要因に基づいて、最初の実行時に自身の「ブロック」サイズを任意に定義します。（私はおそらくその目的、機能、メカニズム、および賛否両論を誤って伝えていると思いますが、私はそれを使用していないため、オプションとして最近評価しただけです。）
ミツバチは間違いなくわずかにハイブリッドっぽく、継続的に実行するように設計されており、ディスクをそれほど強くハンマーで打たないようになっています。実際に重複を取得し、軽いタッチで重複排除を試みるだけです。任意に定義されたブロックサイズでの作業は、設計により、ハッシュテーブルをRAMに適合させることを意味します。（おそらく）欠点は、同じ「ブロック」内にエクステントが存在する可能性があることですが、蜂が含まれている「ブロック」が異なるため、蜂が重複除去できない場合があります。
「ファイル」レベルのBtrfs重複排除を具体的に実行するユーティリティ（bedup、duperemove、rmlintなど）でも、要件を満たしている可能性があることに注意してください。確かではありませんが、確かにそうです。これは、「cp --reflink = always」コマンドでも「ファイル」を実際に重複排除しないためです。Btrfs エクステントを重複排除しています。再リンクされた「ファイル」が変更された場合、Btrfsは、変更されたエクステントのみを重複排除解除して、独自の一意のエクステントにします。ファイルの残りの部分は重複排除されたままです。これが、重複排除された大きなファイルが独自の一意のファイルのように分岐できる方法ですが、ほとんどの場合は重複排除されます。
（これは、「ファイル」がreflinkされているかどうかを判断するのが非常に難しい理由でもあります。その概念は実際には意味をなさないためです。ファイルのすべてのエクステントは、他の同じエクステント自体にreflinkされる可能性があります。理にかなっていますが、それは偶然に答えるのが特に難しい質問です。そのため、Btrfs重複排除ユーティリティがすでに重複排除されたものを追跡しない限り、ファイルがすでに重複排除されているかどうかを「検出」しようとする価値はありません。検査するrefcountのような属性はありません。いずれにしても、重複排除を再度行う方が簡単です。対照的に、ファイル全体が旧式の方法でハードリンクされているかどうかを判断するのは簡単です。特定のiノードのst_nlinkカウントを確認するだけです。）
「ファイル全体のクローン」の欠如は、実際には「無料」のスナップショットや重複排除をサポートするすべてのCoWファイルシステムに固有の機能であり、Btrfsエクステント、ZFSブロック、またはその他のものを処理する場合に当てはまります。どちらかがおそらくあなたの質問への答えになることができる理由です。（私が知っている、それをすべて実行できる、または実行できるように計画されている他のCoWファイルシステムが少なくとも3つあります：nilfs2、bcachefs、およびxfs。）
これについては言及しませんでしたが、私の知る限り、ファイルタイプに対応した重複排除技術はありません。言い換えると、重複排除者は* .jpgメタデータをスキップして、圧縮された画像データのみを重複排除の対象とすることを認識していません。同様に、それらのいずれもファイルのマジックナンバーを考慮していません（少なくとも重複排除について何を考慮すべきかを決定するため）。それはキラー機能になる可能性があります-確かに、継続的で継続的な定義の更新が必要です。また、ファイルをエクステントやブロックなどの抽象的なM：Mコレクションとして扱う一方で、設計が本当に難しい場合もあります。