7 ms·

Thank you! That sentiment on HN about how "Everything should have ECC" really grinds my gears. There is no need for ECC in your iPhone or on your MacBook. Your

Thank you! That sentiment on HN about how "Everything should have ECC" really grinds my gears. There is no need for ECC in your iPhone or on your MacBook. Your average emoji-laden WhatsApp Conversation with your friends does not require Bit Error Correction. People who really need ECC do exactly what you just mentioned: Evaluate, and often enough they will find little to gain from ECC.

sitkack 9y ago
> There is no need for ECC in your iPhone or on your MacBook. Scientists, Engineers and Economists shouldn't use a Phone or MacBook? Your handle is ironic. The lack of ECC is a method to artificially segment markets and nothing more. Not ECC, but "single bit errors" can be fatal in other domains [0] [0] https://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail https://gizmodo.com/382026/a-cellphones-missing-dot-kills-tw...
- sixbrx 9y ago
  I imagine bit errors are highly unwanted on any domain when they occur in pointers, especially on those that are written through. Some languages make that more likely than others of course with heavy use of references.
- Bromskloss 9y ago
  Wow, that story is like Romeo and Juliet, or Pyramus and Thisbe.
- kpxxx3 9y ago
  Lol that is not a single bit error in the slightest. Like that’s the same as reducing airline accidents to just being one little mistake or similarly just casting off challenger as a materials failure.
jmh530 9y ago
But when you need ECC, you really need it. My FreeNAS server has like 32GB or ECC memory because it runs ZFS, which basically doesn't work unless you have ECC memory. However, my desktop computer or my laptop don't need it. When you need ECC, use it, but if you don't need it, then no biggie.
- rightos 9y ago
  Why does ZFS "really need" ECC? I have a few friends running freenas on just old machines without ECC, no issues so far a few years in.
  - slobotron 9y ago
    If anything, ZFS checksumming lets you get by without ECC and still be confident in your data...
    - kobeya 9y ago
      No because the checksums are cached in ram and not verified against the disk when an error occurs.
      - slobotron 9y ago
        Thanks for catching that - my statement was definitely too strong in implying data invulnerability. I was hinting that you still get a bit of extra protection with ZFS over other filesystems, both on Non-ECC RAM. There is a chance with a stuck/corrupt bit that checksum will fail and you will get a read error. I interpreted OP as saying ECC is a must for ZFS, but I don't think you are more prone to corruption that any other FS? I'm basing my understanding on this: http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/ http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-yo...
      - raattgift 9y ago
        Yes-and-no. In the most general case the checksum of data block A lives in the parent block B. B's checksum in turn lives in its parent block. And so forth all the way to the root of the Merkle tree. These checksums are fixed exactly once, in the zio pipeline, as a dirtied buffer is being passed through it during a write operation. The checksum then stays on disk in that form in block B for as long as block A is reachable. In the read case, checksum validation is done at the vdev_{raidz,mirror,...}.c level and repaired there if possible e.g. from another element of the mirror; recovery is also possible in the case of copies=N (N > 1). Generally, the checksums of read data and metadata are not used once a buffer is successfully in the ARC. (However, compare arc_buf_{freeze,thaw}(), which one can enable, and which will happily cause panics if ARC buffers are corrupted whether through physical problems (e.g. in memory, in a bus, in the CPU) or software error in the kernel.) Block B may already be in cache for some other reason, in which case the in-memory checksum is used (this is the "yes" part of "yes-and-no"); otherwise, block B will have to be fetched before block A, because block B is where A's checksum lives. Block B may be evicted from ARC long before block A is evicted; any read() or similar call that needs data from A will not result in B being read back into memory. A buffer kept in ARC and used as the source of subsequently-dirtied data will have its checksum generated anew, just like the fresh write above. Obviously if the data it is dirtied with is bad, it will go to disk and its parents will have a checksum reflecting the bad data. However, the source of the badness need not be within the transient dirtied buffer, nor in a long-resident ARC buffer; userland memory can be corrupted too. If one has bad memory than bad data may end up on disk, checksummed in such a way that the badness will not be detected by the ZFS subsystem. But this is really no different from any other RAID-like data-validating system or a traditional one-disk filesystem which doesn't checksum. If bits are flipped in userland data that is ultimately subjected to a write(2) call (etc., think mmap()), no filesystem can reasonably expect to do anything other than write out the data handed to it via the system call. Like any other filesystem, ZFS has its own metadata for tracking allocations, object metadata, and in generating the branch-to-root Merkle tree. The wrong memory corruption (and this has happened in software during ZFS development) can result in data loss or even a pool too damaged to be imported (go to backups). ZFS is not especially more exposed to that than any other filesystem. Since the arrival of compressed ARC and crypto, only a small fraction of ARC buffers are kept uncompressed or unencrypted in memory at any time (this is controlled by the dbuf cache tunables). Bitflips in any encrypted-in-memory ARC buffer will be caught (noisily) if the buffer is subsequently read or modified, since a decryption will be done at that time and would fail under a single modified bit. Many possible corruptions in compressed-in-memory data will also be caught depending on the type of compression used when the buffer was first written out to disk. In neither case is the ZFS checksum involved in the catching of such corruptions. Finally, this still won't protect against corruptions in userland, corruptions which hit the various data structure that point to buffers in ARC, or corruptions in the text segments in the zfs subsystem or elsewhere in the kernel. However, ZFS is not realisically more fragile to such corruptions than any other filesystem.
frou_dh 9y ago
It’s odd to talk about “needs” like this. iPhones don’t “need” the Secure Enclave either, but never the less it’s great that they have it. It’s some kind of snobbery to advocate that good technology should be held back until non-enterprise plebs demonstrate that they are deserving of it. Just give everyone the good technology as much as is possible. Who’s it hurting if some subjectively underutilise it?
- tokenizerrr 9y ago
  > Just give everyone the good technology as much as is possible. Who’s it hurting if some subjectively underutilise it? Everyone who buys the product and doesn't require the technology, because they'll be spending more money on something they don't need or use.
  - frou_dh 9y ago
    How does someone “not use” ECC RAM when their computer contains it? Computer reliability should be a rising tide. Up-and-to-the-right is the goal.
  - LeifCarrotson 9y ago
    If ECC was the normal product that went into everything, and someone invented "unverified" RAM to get a tiny speed boost and slightly decreased cost, how much do you think the actual price difference would be? I expect it would be tiny. It's a political decision by Intel to make ECC an Xeon-only product which has resulted in the vast majority of the price difference. The silicon die area required for it really doesn't cost that much more - often, the area is present on the consumer dies but just disabled so they can charge a lot more to the enterprise customers who actually require it. And political decisions like that make a lot of HN users unhappy. As Joel Spolsky said in https://www.joelonsoftware.com/2004/12/15/camels-and-rubber-duckies/ https://www.joelonsoftware.com/2004/12/15/camels-and-rubber-...: > Working my way backwards, this business about segmenting? It pisses the heck off of people. People want to feel they’re paying a fair price.... And God help you if an A-list blogger finds out that your premium printer is identical to the cheap printer, with the speed inhibitor turned off. Everyone knows that ECC parts are nearly identical to the cheap parts, with the ECC module turned off. But there's no boycott, because there are (were?) no other options, like there might be for a printer company. ECC segmentation is just something everyone knows and resents.
mozumder 9y ago
ECC increases reliability on older systems as well, increasing lifespan of any product. Silicon degradation is a thing.
muraiki 9y ago
Bitsquatting refers to registering a domain name one bit different from the target domain name. The intent is that a memory error will cause someone to get the bitsquatted site instead of the legitimate one. "During the logging period there were a total of 52,317 bitsquat requests from 12,949 unique IP addresses. When not counting 3 events that caused extraordinary amounts of traffic, an average of 59 unique IPs per day made HTTP requests to my 32 bitsquat domains." http://dinaburg.org/bitsquatting.html http://dinaburg.org/bitsquatting.html Overheating can be a cause of bit errors, and heat is a concern in mobile devices and laptops.
- haikuginger 9y ago
  Now I'm curious to see how different user agents would handle SSL validation for bit errors at different points in the process.

sitkack 9y ago

> There is no need for ECC in your iPhone or on your MacBook. Scientists, Engineers and Economists shouldn't use a Phone or MacBook? Your handle is ironic. The lack of ECC is a method to artificially segment markets and nothing more. Not ECC, but "single bit errors" can be fatal in other domains [0] [0] https://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail https://gizmodo.com/382026/a-cellphones-missing-dot-kills-tw...

sixbrx 9y ago
I imagine bit errors are highly unwanted on any domain when they occur in pointers, especially on those that are written through. Some languages make that more likely than others of course with heavy use of references.
Bromskloss 9y ago
Wow, that story is like Romeo and Juliet, or Pyramus and Thisbe.
kpxxx3 9y ago
Lol that is not a single bit error in the slightest. Like that’s the same as reducing airline accidents to just being one little mistake or similarly just casting off challenger as a materials failure.

jmh530 9y ago

But when you need ECC, you really need it. My FreeNAS server has like 32GB or ECC memory because it runs ZFS, which basically doesn't work unless you have ECC memory. However, my desktop computer or my laptop don't need it. When you need ECC, use it, but if you don't need it, then no biggie.

rightos 9y ago
Why does ZFS "really need" ECC? I have a few friends running freenas on just old machines without ECC, no issues so far a few years in.
- slobotron 9y ago
  If anything, ZFS checksumming lets you get by without ECC and still be confident in your data...
  - kobeya 9y ago
    No because the checksums are cached in ram and not verified against the disk when an error occurs.
    - slobotron 9y ago
      Thanks for catching that - my statement was definitely too strong in implying data invulnerability. I was hinting that you still get a bit of extra protection with ZFS over other filesystems, both on Non-ECC RAM. There is a chance with a stuck/corrupt bit that checksum will fail and you will get a read error. I interpreted OP as saying ECC is a must for ZFS, but I don't think you are more prone to corruption that any other FS? I'm basing my understanding on this: http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/ http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-yo...
    - raattgift 9y ago
      Yes-and-no. In the most general case the checksum of data block A lives in the parent block B. B's checksum in turn lives in its parent block. And so forth all the way to the root of the Merkle tree. These checksums are fixed exactly once, in the zio pipeline, as a dirtied buffer is being passed through it during a write operation. The checksum then stays on disk in that form in block B for as long as block A is reachable. In the read case, checksum validation is done at the vdev_{raidz,mirror,...}.c level and repaired there if possible e.g. from another element of the mirror; recovery is also possible in the case of copies=N (N > 1). Generally, the checksums of read data and metadata are not used once a buffer is successfully in the ARC. (However, compare arc_buf_{freeze,thaw}(), which one can enable, and which will happily cause panics if ARC buffers are corrupted whether through physical problems (e.g. in memory, in a bus, in the CPU) or software error in the kernel.) Block B may already be in cache for some other reason, in which case the in-memory checksum is used (this is the "yes" part of "yes-and-no"); otherwise, block B will have to be fetched before block A, because block B is where A's checksum lives. Block B may be evicted from ARC long before block A is evicted; any read() or similar call that needs data from A will not result in B being read back into memory. A buffer kept in ARC and used as the source of subsequently-dirtied data will have its checksum generated anew, just like the fresh write above. Obviously if the data it is dirtied with is bad, it will go to disk and its parents will have a checksum reflecting the bad data. However, the source of the badness need not be within the transient dirtied buffer, nor in a long-resident ARC buffer; userland memory can be corrupted too. If one has bad memory than bad data may end up on disk, checksummed in such a way that the badness will not be detected by the ZFS subsystem. But this is really no different from any other RAID-like data-validating system or a traditional one-disk filesystem which doesn't checksum. If bits are flipped in userland data that is ultimately subjected to a write(2) call (etc., think mmap()), no filesystem can reasonably expect to do anything other than write out the data handed to it via the system call. Like any other filesystem, ZFS has its own metadata for tracking allocations, object metadata, and in generating the branch-to-root Merkle tree. The wrong memory corruption (and this has happened in software during ZFS development) can result in data loss or even a pool too damaged to be imported (go to backups). ZFS is not especially more exposed to that than any other filesystem. Since the arrival of compressed ARC and crypto, only a small fraction of ARC buffers are kept uncompressed or unencrypted in memory at any time (this is controlled by the dbuf cache tunables). Bitflips in any encrypted-in-memory ARC buffer will be caught (noisily) if the buffer is subsequently read or modified, since a decryption will be done at that time and would fail under a single modified bit. Many possible corruptions in compressed-in-memory data will also be caught depending on the type of compression used when the buffer was first written out to disk. In neither case is the ZFS checksum involved in the catching of such corruptions. Finally, this still won't protect against corruptions in userland, corruptions which hit the various data structure that point to buffers in ARC, or corruptions in the text segments in the zfs subsystem or elsewhere in the kernel. However, ZFS is not realisically more fragile to such corruptions than any other filesystem.

frou_dh 9y ago

It’s odd to talk about “needs” like this. iPhones don’t “need” the Secure Enclave either, but never the less it’s great that they have it. It’s some kind of snobbery to advocate that good technology should be held back until non-enterprise plebs demonstrate that they are deserving of it. Just give everyone the good technology as much as is possible. Who’s it hurting if some subjectively underutilise it?

tokenizerrr 9y ago
> Just give everyone the good technology as much as is possible. Who’s it hurting if some subjectively underutilise it? Everyone who buys the product and doesn't require the technology, because they'll be spending more money on something they don't need or use.
- frou_dh 9y ago
  How does someone “not use” ECC RAM when their computer contains it? Computer reliability should be a rising tide. Up-and-to-the-right is the goal.
- LeifCarrotson 9y ago
  If ECC was the normal product that went into everything, and someone invented "unverified" RAM to get a tiny speed boost and slightly decreased cost, how much do you think the actual price difference would be? I expect it would be tiny. It's a political decision by Intel to make ECC an Xeon-only product which has resulted in the vast majority of the price difference. The silicon die area required for it really doesn't cost that much more - often, the area is present on the consumer dies but just disabled so they can charge a lot more to the enterprise customers who actually require it. And political decisions like that make a lot of HN users unhappy. As Joel Spolsky said in https://www.joelonsoftware.com/2004/12/15/camels-and-rubber-duckies/ https://www.joelonsoftware.com/2004/12/15/camels-and-rubber-...: > Working my way backwards, this business about segmenting? It pisses the heck off of people. People want to feel they’re paying a fair price.... And God help you if an A-list blogger finds out that your premium printer is identical to the cheap printer, with the speed inhibitor turned off. Everyone knows that ECC parts are nearly identical to the cheap parts, with the ECC module turned off. But there's no boycott, because there are (were?) no other options, like there might be for a printer company. ECC segmentation is just something everyone knows and resents.

mozumder 9y ago

ECC increases reliability on older systems as well, increasing lifespan of any product. Silicon degradation is a thing.

muraiki 9y ago

Bitsquatting refers to registering a domain name one bit different from the target domain name. The intent is that a memory error will cause someone to get the bitsquatted site instead of the legitimate one. "During the logging period there were a total of 52,317 bitsquat requests from 12,949 unique IP addresses. When not counting 3 events that caused extraordinary amounts of traffic, an average of 59 unique IPs per day made HTTP requests to my 32 bitsquat domains." http://dinaburg.org/bitsquatting.html http://dinaburg.org/bitsquatting.html Overheating can be a cause of bit errors, and heat is a concern in mobile devices and laptops.

haikuginger 9y ago
Now I'm curious to see how different user agents would handle SSL validation for bit errors at different points in the process.