-----BEGIN PGP SIGNED MESSAGE-----
Am 31.03.14 23:23, schrieb Eric Jaw:
> I completely agree. I'm experiencing these issues currently.
> 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
>> 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
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.
> On Wednesday, February 26, 2014 8:56:50 PM UTC-5, Philip Robar
>> 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
>>  (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.
>>  ECC vs non-ECC RAM and ZFS:
 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/
-----END PGP SIGNATURE-----
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.