There are a few different use cases, but cloning a VM image file is definitely a popular one.
Also, `mv` between different filesystems in the same ZFS pool. Traditionally when crossing filesystems doesn't allow just using `rename()`, `mv` resorted to effectively `cp` then `rm`, so at least temporarily required 2x the space, and that space might not be freed for a long time if you have snapshots.
With BRT, the copy to the 2nd filesystem doesn't need to write anything more than a bit of metadata, and then when you remove the source copy, it actually removes the BRT entry, so there is no long-term overhead.
One of the original developer's use cases was restoring a file from a snapshot, without having to copy it and have it take up additional space.
So you make a file (foo) 2 days ago.
You change it each day.
Today, the change you made was bad, and you want to restore the version from yesterday.
before BRT:
you copied the file from the snapshot back to the live filesystem, and it took up all new space.
after BRT:
we reference the existing blocks in the snapshot, so the copy to the live filesystem takes no additional space on disk. A small BRT entry is maintained in memory (and on disk).
If you remove the snapshot, the BRT entry is removed, and the file remains intact. No long term overhead.
