On Monday, March 31, 2014 9:10:49 PM UTC-4, jasonbelec wrote:
>
> As one who has gone through all kinds of permutations to 'corrupt' data 
> under ZFS, I'm calling BS on the RAM as the culprit. As Bjoern mentioned it 
> sounds like connector issues, something I've seen a lot. However depending 
> how you set your pool up, your data may be difficult to access but most 
> likely complete and healthy. 
>
> It amazes me how willing people are to blame something definitively with 
> so little knowledge of what's going on and determined that quoting some 
> discussion out of context will justify the irrationality. 
>
> These threads are kind of getting redundant, pointless and I think some of 
> these individuals are best served by Drobo or similar technology. 
>
> Jason
> Sent from my iPhone 5S
>

It's true. I just started using ZFS a few weeks ago. It made sense to me, 
since I have no idea why this is happening. I used new cables when I built 
this. I'm using HDD's that were pretty much from the same batch and one 
that I've used really heavily, I would say a good 20:1 compared to these 
four drives in my pool, which have barely been touched.

 

>
> On Mar 31, 2014, at 5:55 PM, Daniel Becker <razz...@gmail.com<javascript:>> 
> wrote:
>
> On Mar 31, 2014, at 2:23 PM, Eric Jaw <nais...@gmail.com <javascript:>> 
> wrote:
>
> Doing a scrub is just obliterating my pool. 
>
>
> Is it? I don’t think so:
>
> 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
>>
>
> Note the “0 repaired.”
>
> I'm also running ZFS on FreeBSD 10.0 (RELEASE) in VirtualBox on Windows 7 
> Ultimate.
>
>
> Are the disks that the VM sees file-backed or passed-through raw disks?
>
> 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.
>
>
> Did you actually run a memory tester (e.g., memcheck86), or is this just 
> based on gut feeling? Lots of things can manifest as checksum errors. If 
> you import the pool read-only, do successive scrubs find errors in 
> different files (use “zpool status -v”) every time, or are they always in 
> the same files? The former would indeed point to some kind of memory 
> corruption issue, while in the latter case it’s much more likely that your 
> on-disk data somehow got corrupted.
>
>

-- 

--- 
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