2012-04-17 14:47, Matt Keenan wrote:
- or is it possible that one of the devices being a USB device is
causing the failure ? I don't know.


Might be, I've got little experience with those beside LiveUSB
imagery ;)

My reason for splitting the pool was so I could attach the clean USB
rpool to another laptop and simply attach the disk from the new laptop,
let it resilver, installgrub to new laptop disk device and boot it up
and I would be back in action.

If the USB disk split-off were to work, I'd rather try booting
the laptop off the USB disk, if BIOS permits, or I'd boot off
a LiveCD/LiveUSB (if Solaris 11 has one - or from installation
media and break out into a shell) and try to import the rpool
from USB disk and then attach the laptop's disk to it to resilver.

As a workaround I'm trying to simply attach my USB rpool to the new
laptop and use zfs replace to effectively replace the offline device
with the new laptop disk device. So far so good, 12% resilvering, so
fingers crossed this will work.

Won't this overwrite the USB disk with the new laptop's (empty)
disk? The way you describe it...

As an aside, I have noticed that on the old laptop, it would not boot if
the USB part of the mirror was not attached to the laptop, successful
boot could only be achieved when both mirror devices were online. Is
this a know issue with ZFS ? bug ?

Shouldn't be as mirrors are to protect against the disk failures.
What was your rpool's "failmode" zpool-level attribute?
It might have some relevance, but should define kernel's reaction
to "catastrophic failures" of the pool, and loss of a mirror's
side IMHO should not be one?.. Try failmode=continue and see if
that helps the rpool, to be certain. I think that's what the
installer should have done.



_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to