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
