On Tuesday, April 1, 2014 12:13:30 AM UTC-4, Daniel Becker wrote:
> 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.
> The counts are not maintained across reboots.
> 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
> What this means is that in these 43 cases, the system was not able to
> correct the error (i.e., both drives in a mirror returned bad data).
> 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.
> The reason I was asking is that these symptoms would also be consistent
> with something outside the VM writing to the disks behind the VM’s back;
> that’s unlikely to happen accidentally with disk images, but raw disks are
> visible to the host OS as such, so it may be as simple as Windows deciding
> that it should initialize the “unformatted” (really, formatted with an
> unknown filesystem) devices. Or it could be a raid controller that stores
> its array metadata in the last sector of the array’s disks.
> I read about this being a possible issue, so I created a partition for all
the drives so Windows see's it as a drive with a partition, rather than
unformatted. No raid controller for this setup
> 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.
> Given that you’re seeing a fairly large number of errors in your scrubs,
> the fact that memtest86 doesn’t find anything at all very strongly suggests
> that this is not actually a memory issue.
It very well likely may not be a memory issue. The tricky part of this
setup is, it's running through a VM with, what-should-be, direct access to
the raw drives. It could be a driver, perhaps that doesn't want to play
I've discovered that with a NAT network, port forwarding does not work
properly, so I'm not discarding possible issues with VirtualBox
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.