no_connection
Patron
- Joined
- Dec 15, 2013
- Messages
- 480
I have run v7 several years with non-ECC memory with no known data loss or errors. So it works just fine, until it won't. Which is why I am migrating all data to a new ECC based server.
ZFS should never panic or hick up on corrupt data or metadata, with metadata being spread out in several copies (from ZFS presentation by Sun)
Yet that happens to regular users as proven above.
Theoretically ZFS should handle a few bitflips in RAM just fine, correcting it's mistake on the next pass. A stuck bit or thrashing RAM, not so much.
If ZFS could detect excessive "random" corruption and halt when all disks appear to generate errors, then that might save the pool. But it would not know the difference between that and resilvering a replaced disk as it uses the same process.
Or better yet, implement memory scrubbing treating every transaction with checksums. Although I doubt that would provide much performance if even implementable.
ZFS should never panic or hick up on corrupt data or metadata, with metadata being spread out in several copies (from ZFS presentation by Sun)
Yet that happens to regular users as proven above.
Theoretically ZFS should handle a few bitflips in RAM just fine, correcting it's mistake on the next pass. A stuck bit or thrashing RAM, not so much.
If ZFS could detect excessive "random" corruption and halt when all disks appear to generate errors, then that might save the pool. But it would not know the difference between that and resilvering a replaced disk as it uses the same process.
Or better yet, implement memory scrubbing treating every transaction with checksums. Although I doubt that would provide much performance if even implementable.