On Monday, March 31, 2014 5:55:21 PM UTC-4, Daniel Becker 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:

Thanks for the response! Here's some more details on the setup: 

I started using ZFS about a few weeks ago, so a lot of it is still new to 
me. I'm actually not completely certain about "proper procedure" for 
repairing a pool. I'm not sure if I'm supposed to clear the errors after 
the scrub, before or after (little things). I'm not sure if it even 
matters. When I restarted the VM, the checksum counts cleared on its own.

I wasn't expecting to run into any issues. But I drew a part of my 
conclusion from the high numbers of checksum errors that never happened 
until I started reading from the dataset and that number went up in the 
tens' when I scrubbed the pool; almost doubling when scrubbed for a second 

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

On the first scrub it repaired roughly 1.65MB. None on the second scub. 
Even after the scrub there were still 43 data errors. I was expecting they 
were going to go away.

errors: 43 data errors, use '-v' for a list


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

This is an excellent question. They're in 'Normal' mode. I remember looking 
in to this before and decided normal mode should be fine. I might be wrong. 
So thanks for bringing this up. I'll have to check it out again.


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

memtest86 and memtest86+ for 18 hours came out okay. I'm on my third scrub 
and the number or errors has remained at 43. Checksum errors continue to 
pile up as the pool is getting scrubbed.

I'm just as flustered about this. Thanks again for the input.


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