7 ms·

Do you use ZFS? If no then you should use ECC memory. Now the half truth becomes full-truth.

mikeash 9y ago
I don't get this association between ZFS and ECC. The recommendation to use ECC with ZFS basically comes down to "all that fancy data integrity checking that ZFS does won't protect you from memory errors, so you'll effectively lose that feature." Are you OK with silent data corruption? If so, don't bother with ECC. If not, use it.
- Spooky23 9y ago
  One of the major reasons for using ZFS is ensuring data integrity. If you implement ZFS for that propose and cheap out on RAM, you're at odds for that purpose.
- __jal 9y ago
  History. The ZFS folks, back when, were the only folks making much noise about the association between non-ECC RAM and corrupt data landing on disk. The truth is, if you care about the notion that your disk should return the same data that software thought it was writing, you should use ECC with any file system. But The ZFS folks made noise about the issue, I think lots of people assumed the reason was that there was something special about ZFS that needed it, and now you have something sort of like an urban legend.
  - dom0 9y ago
    > should return the same data that software thought it was writing Hint: In an OS using a page cache (=every OS) I/O errors are not reliably propagated to applications unless they explicitly sync their dirty pages.
    - __jal 9y ago
      I'm aware of that, but I'm not sure what I'm supposed to take away from it in this context.
      - dom0 9y ago
        That it's difficult to accurately define "what the application thought it wrote" when considering corruption at various abstraction layers; somewhat similar to calculating checksums over already corrupted data.
  - boomboomsubban 9y ago
    Kind of, there are two main things that give ZFS this false reputation. First is an academic paper testing if modern filesystems still needed ECC RAM. They tested ZFS and concluded horrible things could happen to your data without ECC RAM. They found the same about ext2, but that was just a small paragraph people overlooked. So nothing new, but many people are unaware that other FS have the same issue. Second is a moderator on the FreeNAS forums coming up with a scenario where a ZFS scrub would wipe out your data. Developers and other people that have read the code said it couldn't happen as described, but the story was perpetrated on the FreeNAS forums and spread across the net.
- dogma1138 9y ago
  Because with ZFS bit rot can be cumulative, with most file systems a memory error will corrupt a file if the format can't handle errors, with ZFS overtime the entire volume can get corrupted especially when you are doing recovery or expansion, even in normal operation data is moved around quite a bit. For them most part with other common file systems when a file is written it stays there even in RAID.
  - Dylan16807 9y ago
    I don't know, I wouldn't say ZFS moves files around any more than a typical filesystem.
    - blackflame7000 9y ago
      Correct. ZFS won't do unnecessary file reordering unless a scrub has been initiated.
  - wtallis 9y ago
    The only detailed explanations I've ever seen for how memory errors can snowball into whole-filesystem loss on ZFS have relied on the assumption that you have a deterministically stuck bit in a region of memory that the OS is re-using for different parts of the FS data structures but never anything that could cause the machine itself to crash (thereby clueing you in to a hardware reliability issue). Do you have a source for a more plausible analysis that takes into account how memory actually tends to fail?
- bsder 9y ago
  > I don't get this association between ZFS and ECC. Because ZFS was the ONLY file system that would actually catch some memory failures even if you didn't have ECC. So, ZFS got a reputation for being snotty when in reality the hardware it was running on was broken.
blackflame7000 9y ago
Here is an article detailing how ZFS is virtually unaffected by random bit flips because it would have to occur in such a way as to cause a sha256 collision between one block and its parity block in order for it to repair a valid block with a corrupt one during a scrub. Furthermore it goes on to argue that only a highly specific large scale ram corruption could possibly cause corruption and by that time it's almost certain the OS wouldn't boot up. 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...

I don't get this association between ZFS and ECC. The recommendation to use ECC with ZFS basically comes down to "all that fancy data integrity checking that ZFS does won't protect you from memory errors, so you'll effectively lose that feature." Are you OK with silent data corruption? If so, don't bother with ECC. If not, use it.

Spooky23 9y ago
One of the major reasons for using ZFS is ensuring data integrity. If you implement ZFS for that propose and cheap out on RAM, you're at odds for that purpose.
__jal 9y ago
History. The ZFS folks, back when, were the only folks making much noise about the association between non-ECC RAM and corrupt data landing on disk. The truth is, if you care about the notion that your disk should return the same data that software thought it was writing, you should use ECC with any file system. But The ZFS folks made noise about the issue, I think lots of people assumed the reason was that there was something special about ZFS that needed it, and now you have something sort of like an urban legend.
- dom0 9y ago
  > should return the same data that software thought it was writing Hint: In an OS using a page cache (=every OS) I/O errors are not reliably propagated to applications unless they explicitly sync their dirty pages.
  - __jal 9y ago
    I'm aware of that, but I'm not sure what I'm supposed to take away from it in this context.
    - dom0 9y ago
      That it's difficult to accurately define "what the application thought it wrote" when considering corruption at various abstraction layers; somewhat similar to calculating checksums over already corrupted data.
- boomboomsubban 9y ago
  Kind of, there are two main things that give ZFS this false reputation. First is an academic paper testing if modern filesystems still needed ECC RAM. They tested ZFS and concluded horrible things could happen to your data without ECC RAM. They found the same about ext2, but that was just a small paragraph people overlooked. So nothing new, but many people are unaware that other FS have the same issue. Second is a moderator on the FreeNAS forums coming up with a scenario where a ZFS scrub would wipe out your data. Developers and other people that have read the code said it couldn't happen as described, but the story was perpetrated on the FreeNAS forums and spread across the net.
dogma1138 9y ago
Because with ZFS bit rot can be cumulative, with most file systems a memory error will corrupt a file if the format can't handle errors, with ZFS overtime the entire volume can get corrupted especially when you are doing recovery or expansion, even in normal operation data is moved around quite a bit. For them most part with other common file systems when a file is written it stays there even in RAID.
- Dylan16807 9y ago
  I don't know, I wouldn't say ZFS moves files around any more than a typical filesystem.
  - blackflame7000 9y ago
    Correct. ZFS won't do unnecessary file reordering unless a scrub has been initiated.
- wtallis 9y ago
  The only detailed explanations I've ever seen for how memory errors can snowball into whole-filesystem loss on ZFS have relied on the assumption that you have a deterministically stuck bit in a region of memory that the OS is re-using for different parts of the FS data structures but never anything that could cause the machine itself to crash (thereby clueing you in to a hardware reliability issue). Do you have a source for a more plausible analysis that takes into account how memory actually tends to fail?
bsder 9y ago
> I don't get this association between ZFS and ECC. Because ZFS was the ONLY file system that would actually catch some memory failures even if you didn't have ECC. So, ZFS got a reputation for being snotty when in reality the hardware it was running on was broken.

blackflame7000 9y ago

Here is an article detailing how ZFS is virtually unaffected by random bit flips because it would have to occur in such a way as to cause a sha256 collision between one block and its parity block in order for it to repair a valid block with a corrupt one during a scrub. Furthermore it goes on to argue that only a highly specific large scale ram corruption could possibly cause corruption and by that time it's almost certain the OS wouldn't boot up. 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...