Oh so it doesn't avoid bit rot the way ZFS does (by checksumming)? Mdadm, not being a filesystem, doesn't concern itself with file integrity. I don't suppose LVM would either :(
https://docs.redhat.com/fr/documentation/red_hat_enterprise_...
When creating a RAID LV with integrity, or adding integrity, space is required for integrity metadata. Every 500MB of LV data requires an additional 4MB to be allocated for integrity metadata, for each RAID image.
Also:
The following are not yet permitted on RAID LVs with integrity: lvreduce, pvmove, snapshots, splitmirror, raid syncaction commands, raid rebuild.
The typical workaround for these seems to be remove the integrity, make the change, then add/reinitialize the integrity metadata.
You don't have parity data on RAID1, unless you've got a fancy enterprise setup with irregular size blocks. Most hobbyists don't, and it's probably not even possible on most NVMes.
I think this is most helpful on RAID1, where you can have cases where there's a discrepancy but both disks can read the sector, so you have no idea which one is right.
Every modern harddrive, and most if not all nvme/sata SSDs have built in error correction as part of the encode/decode of your data to the media/flash, Combined with link layer data integrity protection/etc the most likely place for data corruption is low end intel machines without ECC ram, or really old arm designs that don't have cache/interconnect protections, which don't have ECC ram either.
So, the drive usually has far better error correction and detection than your getting with these software algorithms and running the mdadm, scrubbing is more than sufficient to detect basically 100% of 'bitrot'.
There is a ton of false information all over the internet about RAID1 vs RAID5/6, and this article is in the same boat WRT why one would prefer RAID1 vs one of those. (Clue, it has absolutely nothing to do with data integrity).
Pretty much everyone running a home NAS is going to be better off with just a RAID5 + regular scrubbing, vs all this other nonsense. For people who want something a bit better RAID6+scrubbing and then a DIX/DIF enabled path. I think your more likely to hit a critical ZFS bug, than have a problem with a well maintained raid5 setup running on reliable hardware. Think ECC + working AER/MCE/etc RAS reporting. Nevermind that pretty much none of these applications close the loop on their own data manipulation and that fancy new database your running overwriting the wrong record won't be saved by anything other than a good snapshot/backup mechanism.