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/>
>  
>
> >> [1] (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. [2] (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 [3]--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 
> >> 
> >> [1] ECC vs non-ECC RAM and ZFS: 
> >> 
> http://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/ 
> >> 
> >> 
> >> 
> [2] 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." 
> >> 
> >> [3] 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.

Reply via email to