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 

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.

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


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