On 01/20/10 04:27 PM, Cindy Swearingen wrote:
Hi Frank,
I couldn't reproduce this problem on SXCE build 130 by failing a disk in
mirrored pool and then immediately running a scrub on the pool. It works
as expected.
As noted, the disk mustn't go offline until well after the scrub has started.
There's another wrinkle. There are some COMSTAR iscsi targets on this
pool. If there are no initiators accessing any of them, the scrub completes
with no errors after 6 hours. If one specific target is active, the panic
ensues reproducibly at about 5h30m or so.
The precise configuration has 2 disks on one LSI controller as a
mirrored pool (whole disks - no slices). Around 750GB of 1.3TB was
in use when the most recent iscsi target was created. The pool
is read-mostly, so it probably isn't fragmented. The zvol has
copies=1; compression off (no dedupe with snv124). The initiator
is VirtualBox running on Fedora C10 on AMD64 and the target disk
has 32 bit Fedora C12 installed as "whole disk", which I believe is EFI.
To reproduce this might require setting up a COMSTAR iscsi
target on a mirrored pool, formatting it with an EFI label, and
then running a scrub. Another, similar, target has OpenSolaris
installed on it, and it doesn't seem to cause a panic on a scrub
if it is running; AFAIK it doesn't use EFI, but I have not run
a scrub with it active since converting to COMSTAR either.
This wouldn't explain why one or the other disk randomly goes
offline and it may be a red herring. But the scrub now runs to
completion just as it always has. Since I can't get FC12 to boot
from the EFI disk in VirtualBox, I may reinstall FC12 without
EFI and see if that makes a difference, but it is an extremely
slow process since it takes almost 6 hours for the panic to occur
each time and there's no practical way to "relocate" the zvol
to the start of the pool.
HTH -- Frank
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
