-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.03.14 23:23, schrieb Eric Jaw: > I completely agree. I'm experiencing these issues currently. > Largely. > > Doing a scrub is just obliterating my pool. > > > scan: scrub in progress since Mon Mar 31 10:14:52 2014 >> 1.83T scanned out of 2.43T at 75.2M/s, 2h17m to go 0 repaired, >> 75.55% done config: >> >> NAME STATE READ WRITE CKSUM >> moon ONLINE 0 0 91 >> mirror-0 ONLINE 0 0 110 >> diskid/DISK-VB92cae47b-31125427p1 ONLINE 0 0 112 >> diskid/DISK-VBd1496f13-1a733a17p1 ONLINE 0 0 114 >> mirror-1 ONLINE 0 0 72 >> diskid/DISK-VB343ad927-b4a3f4f8p1 ONLINE 0 0 77 >> diskid/DISK-VB245c2429-c36e13b0p1 ONLINE 0 0 74 logs >> diskid/DISK-VB98bcd93f-cdf5113fp1 ONLINE 0 0 0 >> cache diskid/DISK-VB56c14272-ddacbe50p1 ONLINE 0 0 >> 0 >> >> errors: 43 data errors, use '-v' for a list >> > > > I'm using RAM that is definitely non-ECC. They are: + OCZ Reaper > HPC DDR3 PC3-12800 (ocz3rpr1600lv2g) 3x2GB + Corsair Vengeance > (cmz12gx3m3a1600c9) 3x4GB > > I'm also running ZFS on FreeBSD 10.0 (RELEASE) in VirtualBox on > Windows 7 Ultimate. > > Things seem to be pointing to non-ECC RAM causing checksum errors. > It looks like I'll have to swap out my memory to ECC RAM if I want > to continue this project, otherwise the data is pretty much hosed > right now.
In all due respect, but to me this looks more like a bad drive connection or more likely a dying controller than ECC vs. non-ECC RAM. Random bit-flips, which ECC RAM is supposed to detect and correct, are extremely rare in an otherwise healthy system. And as the name says, they are random, i.e. not located at a fixed memory position but instead "jumping around" in the address range. So if there should ever be a bit flip in the ARC that happens after checksumming and before written out to disc (the only way to write a bad checksum to disk I can think of), than it would be either dropped soon after from ARC or overwritten with a new read. In either case, statistically a long time would pass before the next time a bit flip hit some other active data. One of my machines (an old 32 bit Athlon) showed a similar pattern of checksum errors that could be traced to a weak SATA controller: I got massive checksum errors on the four internal links when all four channels were simultaneously active. The situation greatly improved after rewiring the drives and making sure the SATA cables keep a minimum distance of 1-2 cm from each other. Apparently in my case it was a cross-talk problem. Best regards Björn > On Wednesday, February 26, 2014 8:56:50 PM UTC-5, Philip Robar > wrote: >> >> Please note, I'm not trolling with this message. I worked in >> Sun's OS/Net group and am a huge fan of ZFS. >> >> The leading members of the FreeNAS community make it >> clear<http://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/> >>  (with a detailed explanation and links to reports of data >> loss) that if you use ZFS without ECC RAM that there is a very >> good chance that you will eventually experience a total loss of >> your data without any hope of recovery.  (Unless you have >> literally thousands of dollars to spend on that recovery. And >> even then there's no guarantee of said recovery.) The features of >> ZFS, checksumming and scrubbing, work together to silently spread >> the damage done by cosmic rays and/or bad memory throughout a >> file system and this corruption then spreads to your backups. >> >> Given this, aren't the various ZFS communities--particularly >> those that are small machine oriented --other than FreeNAS >> (and even they don't say it as strongly enough in their docs), >> doing users a great disservice by implicitly encouraging them to >> use ZFS w/o ECC RAM or on machines that can't use ECC RAM? >> >> As an indication of how persuaded I've been for the need of ECC >> RAM, I've shut down my personal server and am not going to access >> that data until I've built a new machine with ECC RAM. >> >> Phil >> >>  ECC vs non-ECC RAM and ZFS: >> http://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/ >> >> >>  cyberjock: "So when you read about how using ZFS is an "all or none" >> I'm not just making this up. I'm really serious as it really does >> work that way. ZFS either works great or doesn't work at all. >> That really truthfully [is] how it works." >> >>  ZFS-macos, NAS4Free, PC-BSD, ZFS on Linux >> >> > - -- | Bjoern Kahl +++ Siegburg +++ Germany | | "googlelogin@-my-domain-" +++ www.bjoern-kahl.de | | Languages: German, English, Ancient Latin (a bit :-)) | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQCVAgUBUznj8lsDv2ib9OLFAQLo8wP/SkuFv8lYZdP2+8wuazrPCcLJtToAhoIf 7LVaRznmkrMPOBiDgmcBG+vZbT6y8KRYvsH8D60W33KFASJE4Qj3NIu+kX3I94Ol UfbcIuivc3VAVCCLNoxVv3khzDEBg9pk7kcF2Yy65ot+xR1l5zLvMWeP7Cult9Xc 60+9aEyIOOE= =lrdh -----END PGP SIGNATURE----- -- --- You received this message because you are subscribed to the Google Groups "zfs-macos" group. To unsubscribe from this group and stop receiving emails from it, send an email to zfs-macos+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.