On Monday, March 31, 2014 5:53:59 PM UTC-4, Bjoern Kahl wrote: > > -----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 >
I just started using ZFS a few weeks ago. Thanks for the idea! I used all new SATA cables when I built this I have no idea what's causing this, so I posted some more details here: https://forums.virtualbox.org/viewtopic.php?f=6&t=60975 @Daniel Becker has a very good point about how I have the disks set. I'll have to look into that some more > > > 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.