upvote

points

by Confiks12 hours ago |
comments
upvoteby dijit11 hours ago|
next
[-]
Usually if you’re using a NAS you don’t want to lose data, ZFS is not significantly more sensitive than everything else.

But everything is actually quite sensitive.

We’ve accepted lack of ECC because Intel decided it would be a product line differentiator, and serious customers who didn’t want random crashes or to lose data would buy chips with ECC.

It’s actually less of an issue these days because DDR5 has (by spec) some in-line ECC; won’t help with multi-bit errors but its an improvement on what came before.

reply
upvoteby toast03 hours ago|
parent|
next
[-]
> We’ve accepted lack of ECC because Intel decided it would be a product line differentiator, and serious customers who didn’t want random crashes or to lose data would buy chips with ECC.

AMD has been allowing ECC on lots of regular hardware for a long time.

People don't tend to buy ECC for desktop use because it costs significantly more (used server ram is/was often cheap... but it often doesn't work in desktop boards), and the performance specs are poor.

My home servers are mostly retired desktops, so they get my old desktop ram and I don't want to pay premium prices for jedec speed ecc ram on my desktops, thanks.

Since DDR5 doesn't include reporting on bit errors (afaik), it likely means much fewer single bit errors, but most experienced errors will be multi-bit. Although, I dunno what proportion of bit errors is on the ram chips and what's on the bus... there's no protection from bus errors.

If there were reporting, you could replace chips with high error rates, but without reporting you'll keep running them until they fail enough to notice.

reply
upvoteby layer86 hours ago|
parent|
prev|
next
[-]
DDR5 on-die ECC is to achieve acceptable yields in the face of denser process nodes that decrease the reliability of RAM cells. It’s not clear how much of an improvement that is to what we had before, other than allowing for higher RAM speeds. It doesn’t replace side-band ECC.
reply
upvoteby sgt10 hours ago|
parent|
prev|
[-]
I know that LPDDR5 has ECC, and not just single bit AFAIK, but if you enable it you lose some memory capacity (the 128 bit bus minus 16 bit for ECC error correction, making it effectively 112 bits)
reply
upvoteby StrangeWill11 hours ago|
prev|
next
[-]
The only hangup with the myth "debunking" is that the point is that the corruption doesn't happen to a per-disk buffer, but to the in-flight data before it's persisted to your stripe.

Which means all copies of the data will be corrupted. This can be anything from an irrecoverable file to complete filesystem corruption.

But generally, yeah, not any more dangerous than any other filesystem, and ECC used to be cheap so it was a no-brainer, you should have backups anyway TBH if we're being honest about storage resiliency.

What has been debunked is the "scrub of death" issue, on a scrub a bad bit flip would cause an error, which would be copied over with good data -- well it was technically good before. It would be statistically difficult to have a fault on a read, then a clean read, then a second bit flip destroying the data.

reply
upvoteby magicalhippo11 hours ago|
prev|
[-]
Updated link to the post from Matt Ahrens here[1], which is one of the ZFS creators[2] not "just" a core developer.

[1]: https://arstechnica.com/civis/threads/ars-walkthrough-using-...

[2]: https://en.wikipedia.org/wiki/ZFS#2004%E2%80%932010:_Develop...

reply