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


> 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 :-)) |
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/



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