2 ms·

Yes it does or I don't understand that: http://louwrentius.com/please-use-zfs-with-ecc-memory.html http://louwrentius.com/please-use-zfs-with-ecc-memory.html ht

by Thaxll 12y ago

Yes it does or I don't understand that: http://louwrentius.com/please-use-zfs-with-ecc-memory.html http://louwrentius.com/please-use-zfs-with-ecc-memory.html https://pthree.org/2013/12/10/zfs-administration-appendix-c-why-you-should-use-ecc-ram/ https://pthree.org/2013/12/10/zfs-administration-appendix-c-... Always fun to post on HN and getting downvoted ;o

XorNot 12y ago
The first article doesn't contribute useful metrics - it simply infers that it would be bad. Here's the thing: have you run filesystem recovery tools lately? Because if you're at that point, your data is toast. It's toast if you were running mdadm or RAID. It's toast if a file gets deleted and recovered by ext3/4 (good luck figuring out which chunk you're looking at in lost+found). The second article is simply stressing my original point: ZFS cannot protect you from bad RAM. No file system can. If data is corrupted in RAM, ZFS will checksum that and write it to disk. This is exactly what will happen with any other filesystem. ZFS storage pools can recover from fairly dramatic failures. You can lose a disk out of a non-redundant stripe and still have complete metadata (just incomplete data, but checksums tell you exactly what you lost). Unimportable pools are not something that easily happens without severe damage - a corrupted uberblock can recovered by using the zpool import -T to rewind a txg and get back a verifiably complete copy of your data. This idea that somehow the failure mode of other filesystems to faulty RAM is better is destructive fiction. You have no idea if your data is valid on disk. You have no way to verify if the data is valid in the first place. And the degree and number of failures required to wipe out a pool would also wipe out any other storage system. The idea that recovery tools will save you in a catastrophic failure (of what kind?) is laughable. This can be trivially explored by trying to recover a deleted file in ext4. Sure, it can technically be done. Good luck with doing it more then once.
- kurlberg 12y ago
  As far as I've understood, the gist of the "ZFS without ECC is scary"-mantra is that one bad memory location (say a flaw that results in a word always getting zeroed) might corrupt all your on disk data due to scrubbing ("read data, compute checksum, write data, repeat") Is this in fact a non-issue with ZFS?
  - ryao 12y ago
    The mechanism that you describe should be impossible to achieve with one bit-flip. I have no idea how you came to think this.
    - takeda 12y ago
      There's a lot of misconception spread by FreeNAS forums. I suspect that's where he read it from: http://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/ http://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-r... The author there makes some crazy assumptions like this: "But, now things get messy. What happens when you read that data back? Let's pretend that the bad RAM location is moved relative to the file being loaded into RAM. Its off by 3 bits and move it to position 5."
      - kurlberg 12y ago
        This is indeed where I read it. When googling to find it again I found a similar story at: https://pthree.org/2013/12/10/zfs-administration-appendix-c-why-you-should-use-ecc-ram/ https://pthree.org/2013/12/10/zfs-administration-appendix-c-... Any good ideas on how one might fix this incorrect "common wisdom"?
        takeda 12y ago
        Honestly no idea, except just pointing it out when someone mentions it. The whole ECC recommendation is due to ZFS (unlike other filesystems) providing guarantees to data correctness, but as you know while ZFS can discover data corruption on the disk thanks to checksums, it can't guarantee data correctness in RAM because because as any program it is bound to trust it. That's why ECC RAM is highly recommended.
        ryao 12y ago
        I think there is some confusion about the impact of bit flips on reads and on writes. Those are separate cases. That blog post is absolutely correct, but it talks about writes. People here are talking about reads.

by Thaxll 12y ago

XorNot 12y ago

The first article doesn't contribute useful metrics - it simply infers that it would be bad. Here's the thing: have you run filesystem recovery tools lately? Because if you're at that point, your data is toast. It's toast if you were running mdadm or RAID. It's toast if a file gets deleted and recovered by ext3/4 (good luck figuring out which chunk you're looking at in lost+found). The second article is simply stressing my original point: ZFS cannot protect you from bad RAM. No file system can. If data is corrupted in RAM, ZFS will checksum that and write it to disk. This is exactly what will happen with any other filesystem. ZFS storage pools can recover from fairly dramatic failures. You can lose a disk out of a non-redundant stripe and still have complete metadata (just incomplete data, but checksums tell you exactly what you lost). Unimportable pools are not something that easily happens without severe damage - a corrupted uberblock can recovered by using the zpool import -T to rewind a txg and get back a verifiably complete copy of your data. This idea that somehow the failure mode of other filesystems to faulty RAM is better is destructive fiction. You have no idea if your data is valid on disk. You have no way to verify if the data is valid in the first place. And the degree and number of failures required to wipe out a pool would also wipe out any other storage system. The idea that recovery tools will save you in a catastrophic failure (of what kind?) is laughable. This can be trivially explored by trying to recover a deleted file in ext4. Sure, it can technically be done. Good luck with doing it more then once.

kurlberg 12y ago
As far as I've understood, the gist of the "ZFS without ECC is scary"-mantra is that one bad memory location (say a flaw that results in a word always getting zeroed) might corrupt all your on disk data due to scrubbing ("read data, compute checksum, write data, repeat") Is this in fact a non-issue with ZFS?
- ryao 12y ago
  The mechanism that you describe should be impossible to achieve with one bit-flip. I have no idea how you came to think this.
  - takeda 12y ago
    There's a lot of misconception spread by FreeNAS forums. I suspect that's where he read it from: http://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/ http://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-r... The author there makes some crazy assumptions like this: "But, now things get messy. What happens when you read that data back? Let's pretend that the bad RAM location is moved relative to the file being loaded into RAM. Its off by 3 bits and move it to position 5."
    - kurlberg 12y ago
      This is indeed where I read it. When googling to find it again I found a similar story at: https://pthree.org/2013/12/10/zfs-administration-appendix-c-why-you-should-use-ecc-ram/ https://pthree.org/2013/12/10/zfs-administration-appendix-c-... Any good ideas on how one might fix this incorrect "common wisdom"?
      - takeda 12y ago
        Honestly no idea, except just pointing it out when someone mentions it. The whole ECC recommendation is due to ZFS (unlike other filesystems) providing guarantees to data correctness, but as you know while ZFS can discover data corruption on the disk thanks to checksums, it can't guarantee data correctness in RAM because because as any program it is bound to trust it. That's why ECC RAM is highly recommended.
      - ryao 12y ago
        I think there is some confusion about the impact of bit flips on reads and on writes. Those are separate cases. That blog post is absolutely correct, but it talks about writes. People here are talking about reads.