Hello... Since there has been much discussion about zpool import failures
resulting in loss of an entire pool, I thought I would illustrate a scenario
I just went through to recover a faulted pool that wouldn't import under
Solaris 10 U5. While this is a simple scenario, and the data was not
terribly important, I think the exercise should at least give some piece of
mind to those who are not always satisfied with the idea that something that
remains a problem in Solaris 10 Ux has been resolved in OpenSolaris. The
end result is that I'm still running Solaris 10 U5 with a pool full of
uncorrupted data.
I have been evaluating a Sun Fire X4500. It came with Solaris 10 U5
pre-installed, and went through the config steps leaving most items for
defaults.
I created 1 zpool with 8 raidz vdevs and two spares, each vdev having target
n from each controller with the exception of two vdevs which have the
bootable components and the two spares.. During the evaluation it was
discovered that in order to share iscsi targets with some iscsi intiators I
should switch over to 2008.05. I thought I would simply just be able to
install 2008.05 over top of Sol10U5 and import / upgrade the pool and move
on. Indeed I probably can do that, but it didn't quite go as planned...
So under U5, the boot devices (mirrored w/ SVM) were c0t1d0 and c5t0d0, I
exported the zpool and rebooted. Through the ILOM's Java console I mounted
the 2008.05 iso and booted from it. When the OS came online, I quickly
started the installer and selected the device labeled c0t1d0 to as the
installation target.... this was rather stupid on my part.... After
rebooting when the install completed I quickly found myself loading Solaris
10 U5 again? Huh?!? Unfortunately, the disk naming was not consistent...
2008.05's c0t1d0 was U5's c4t0d0 a member of the first raidz vdev. Solaris
10 U5 booted up with lots of service faults about not being able to import
the pool. (See the zpool import output below) Zpool import showed an
additional pool called rpool (from the 2008.05 install), but I could not act
on that pool as it is a more advance verion of ZFS than U5 understands.
So, after discovering this, I booted back to the 2008.05 iso and destroyed
the rpool on c4t0d0, thinking all might be ok afterwards with just some
resilvering action being required. Booting back into U5, zpool import still
reports the following...
[EMAIL PROTECTED]:/]# zpool import
pool: tank
id: 12280374646305972114
state: FAULTED
action: The pool cannot be imported due to damaged devices or data.
config:
tank UNAVAIL insufficient replicas
raidz1 UNAVAIL corrupted data
c0t0d0 ONLINE
c1t0d0 ONLINE
c4t0d0 ONLINE
c6t0d0 ONLINE
c7t0d0 ONLINE
. . . .<snip>. . . .
Booting again into the iso for 2008.05, zpool import showed the pool in
degraded state. I was able to replace the failed disk with a spare, and
then revert back to U5 and import the pool successfully, replace the spare
with the original drive, and then reconfigure the spare. So now I'm back to
running Solaris 10 U5 stable with my 44 disk pool full of iscsi volumes.
Point being that even if you can't run OpenSolaris due to support issues,
you may still be able to use OpenSolaris to help resolve ZFS issues that you
might run into in Solaris 10.
Apologies for not having any command history under 2008.05 to show off. I
was using the ILOM console to mount the 2008.05 iso and unfortunately
there's no copy/paste between the ILOM console and my workstation. In all
it was a quite simple fix, just took me a while to wrap my brain around how
to go about it.
--
Ignorance: America's most abundant and costly commodity.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
