So that for instance a 64 gigabyte would have a filesystem with 32 gigabyte space but with a lot of redundancy?
I know there are many ways to achieve similar outcomes but all I know of relies on knowing beforehand how to mount the thing.
And since it's a dataset setting instead of a pool setting, it can be applied selectively on a storage device.
"Oh, those photos are also backed up to Google Photos. It's maybe not ideal, but it's a lot of data and not worth keeping 2 copies those locally, so I'll leave those at the default of copies=1. But the this collection of code and short stories and I've written? That's pretty important to me, and it's actually kind of small -- I'll set that as copies=2. Actually, maybe copies=3 would be even better..."
The setting will stick with it between machines/sessions/whatevers without further user input. Things with copies=2 get mounted the same way as anything else is with ZFS in a given environment.
ZFS already detects bitrot very well even with copies=1, but it can't fix bitrot with chechsums alone. With copies=2, it has a non-zero chance at actually fixing it (or at least being completely readable so the data can be transitioned to the next storage device, completely intact).
https://docs.oracle.com/cd/E19253-01/819-5461/gevpg/index.ht...
In a multiple device pool (with some redundancy) it would IMO be a extra and unneeded layer of protection.
Backups are better (if they actually get done, and if they are actually usable for recovery).
Backups + RAID is better yet.
But OP asked for a particular set of things that do not have any direct relationship to the traditional concepts of either backups or RAID, and ZFS can provide that set of things using copies=2.
It isn't for us to decide the value of this for them.
The card is unaware of which bits of data are duplicates, and therefore can easily end up storing both copies of some data on areas of the physical flash that are weak - and this is even more likely considering they will probably be written around the same timestamp.