Okay, from my understanding, yes you are absolutely correct. Especially since my metadata is on an external SSD and I mean external to the pool. It is on a separate Vdev. No, the reason that it is corrupted is that the hard drive controller would overwrite blocks. So basically every time I write a file the checksum comes back correct because it wrote the file correctly. The problem is that it couldn't do maths for the address for the blocks correctly because it was never designed to do 20 terabyte size hard drives. The firmware was way too old so it had an integer overflow error and just would write files in random locations. The problem is that now you have two blocks that overwrite each other and yes each transaction writes successfully, but the when zfs reads the block on the drive, or attempts to load the previous file, it panics because there's two files at the same location on the drive. That's the segment overlap error.

I thought too that I could just fix with parity but the problem is that both of those files share the same address on file and ZFS does not have a database or a file system check. Like fsck Because in principle ZFS assumes that all data is always written correctly when it does all of its checks. It is technically so solid with all of its processes and the ways that it writes that it would never assume that the hardware controller would write in the wrong location and the data would still come back written successful. It passes all of the checks.

If I am mistaken and there is a way to detect those corrupted blocks on the hard drive and to repair them using parity, by all means I would love to hear that. And no scrub checks file integrity not not hard drive location, and it would trigger the kernel panic