> There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.
[0] https://arstechnica.com/civis/viewtopic.php?p=26303271#p2630...
Ooooo, I hadn't heard about that one. I have one non-ECC box running ZFS where I might want to enable this. If the performance impact is negligible, it'd be worth trying.
Assuming a memory error somewhere:
On ZFS you'd be writing bad data with a bad checksum, which would be caught by ZFS later on.
On (most) other filesystems you'd be writing bad data and no checksum, and you'd be none the wiser until garbage comes back.
It's a myth that ZFS requires ECC memory; ZFS is safer when running with ECC, but without ECC it will still save your data in a lot of places where most other filesystems won't.
See https://www.reddit.com/r/zfs/comments/7ng231/does_a_zfs_mirr... for a bunch of links on this.
Edit: To add on to this, ZFS doesn't do parity-based repair at the checksum level. In the mentioned case (good data, bad checksum) no copy of the block will match the checksum and there will be no supposedly-good block to copy over.
Only difference is that other filesystems may have better tools to rescue damaged filesystem after metadata is corrupted.
Does it use ECC memory? If not, you should not use ZFS. Without ECC memory, ZFS carries the nasty risk of writing good data with a bad checksum, leading to data loss which would not occur in other filesystems (those that do not try to correct errors on the fly like ZFS).