Borg/Restic are deduplicating backup tools. They actually use the exact same approach as ZFS deduplication, but because e.g. Borg chunks are around 2M instead of 128K (ZFS recordsize default) it uses less memory for the same data compared to ZFS. All of these systems end up using somewhere around 300 bytes of memory per chunk stored. [1] This is how you arrive at the "1 GB of memory per 1 TB of storage" rule of thumb when using deduplication.

Block cloning is different because it's offline. It does not require deduplication tables, therefore does not require those 300 bytes per chunk I mentioned above, neither on-disk nor in-core. Note that the BRT only has to track blocks which are actually referenced at least twice, while the DDT has to track all blocks. This, plus the BRT not having to store the block checksum, is why it has so much less overhead. The BRT should come out to less than 20 bytes per tracked block on average. (Also, the BRT is only used for freeing blocks and when handling ficlonerange, while the DDT has to be consulted for every prospective block write).

The downside is of course that it's offline. So the finding of duplicate blocks, which is what all the DDT overhead supports, has to be done by an external tool, unless you're explicitly creating duplicates (cp --reflink=always), which is of course a very useful thing to have -- especially because block cloning works across datasets: with block cloning you can actually copy data out of snapshots back into a writable dataset without having to physically copy anything. Also, again, as it's offline, you can deduplicate existing data in-place, while traditional ZFS dedup would require turning deduplication on and then re-writing all data you want deduplicated.

So OpenZFS 2.2 is definitely going to be very exciting.

[1] Some use more memory in-core than on-disk, e.g. Restic tends to use about 2-3x the memory relative to Borg, Rustic is somewhere in-between. Probably GC tax.