3 ms·
Yes:)) Every chunk of data is hashed, metadata and all. That result is saved on disk, attached to that data. If there is a bit flip before the data or hash of t
by jakeogh 6y ago
Yes:)) Every chunk of data is hashed, metadata and all. That result is saved on disk, attached to that data. If there is a bit flip before the data or hash of the data is written, there is no way to deal with that (how would the code know?). (technically, there are ways to write code that uses more energy... related to statistical computing that can detect bad results, but that is another subject)
Most filesystems silently ignore the error, and most file formats deal with it, or it's something you save but dont recall. ZFS lets you know. When you go back later, that checksum, if a bit was flipped while in memory, it's wrong and does not match the checksum (really it's a crypto hash if you use sha3) of the data on disk. Either the data was written incorrectly, or the hash was calculated incorrectly.
I _kinda_ hit the latter. The MSB of the _address_ (and hence the metadata hash) to the location on disk of the data was flipped in rare cases due to bad RAM. It was always the MSB, a clear hardware error... So the record would point to a "block" out at 128PB. Errors like this might not be found by memtest, because most of the time, that bit works... hence the ECC recommendation. Other hashed filesystems (is btrfs the only one?) would have also detected that problem, because they checksum the data and metadata too(?), but it's a random artifact of the exact hardware problem I had, and ZFS dealt with it gracefully. I was able to RO mount and get my data, and the developers were very helpful. It's mature code, and I like the license.
EDIT:
I'm rate limited... I would reply to your comment directly, but I can (thank you YC! this is a _fantastic_ forum and the rules and moderation are solid) still do so here:
So far, we have no way to 100% shield against ionizing radiation. We can only use redundant memory locations to statistically verify any single bit was not accidentally flipped by a high energy particle/photon.
Even if you surrounded the computer with low background material[1] perhaps buried a mile underground to shield from protons and gamma rays from (we dont really know[2]) that have the energy of a baseball, the material the memory is made out of will still have unstable isotopes which decay and occasionally generate a photon or particle with enough energy to flip that tiny capacitor.
I use ECC everywhere my hardware supports it.
[1] https://www.nuclear-shields.com/radiation-shielding/lead-shielding/low-background-lead.html https://www.nuclear-shields.com/radiation-shielding/lead-shi...
[2] https://en.wikipedia.org/wiki/OMG_particle https://en.wikipedia.org/wiki/OMG_particle (this page should survive the inevitable death of wikipedia)
- nuker 6y agoThanks! In the article: "ZFS and Btrfs provide a bit-rot protection at the same level of SnapRAID, always checking data before using it." Does it mean that Btrfs and SnapRAID need ECC too or they have some workarounds for using non-ECC?