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
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:
@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<
> >>  (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:
>  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.