Hi Kyle,
Except that in the case of spares, you can't replace them.
You'll see a message like the one below.
Cindy
# zpool create pool mirror c1t0d0 c1t1d0 spare c1t5d0
# zpool status
pool: pool
state: ONLINE
scrub: none requested
config:
NAMESTATE READ WRITE CKSUM
Hi Will,
Since no workaround is provided in the CR, I don't know if importing on
a more recent OpenSolaris release and trying to remove it will work.
I will simulate this error, try this approach, and get back to you.
Thanks,
Cindy
On 08/04/09 18:34, Will Murnane wrote:
On Tue, Aug 4,
Hi Will,
I simulated this issue on s10u7 and then imported the pool on a
current Nevada release. The original issue remains, which is you
can't remove a spare device that no longer exists.
My sense is that the bug fix prevents the spare from getting messed
up in the first place when the device
Will Murnane wrote:
I'm using Solaris 10u6 updated to u7 via patches, and I have a pool
with a mirrored pair and a (shared) hot spare. We reconfigured disks
a while ago and now the controller is c4 instead of c2. The hot spare
was originally on c2, and apparently on rebooting it didn't get
I'm using Solaris 10u6 updated to u7 via patches, and I have a pool
with a mirrored pair and a (shared) hot spare. We reconfigured disks
a while ago and now the controller is c4 instead of c2. The hot spare
was originally on c2, and apparently on rebooting it didn't get found.
So, I looked up
Hi Will,
It looks to me like you are running into this bug:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6664649
This is fixed in Nevada and a fix will also be available in an
upcoming Solaris 10 release.
This doesn't help you now, unfortunately.
I don't think this ghost of a
On Tue, Aug 4, 2009 at 19:05, cindy.swearin...@sun.com wrote:
Hi Will,
It looks to me like you are running into this bug:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6664649
This is fixed in Nevada and a fix will also be available in an
upcoming Solaris 10 release.
That
We ran into something similar with controllers changing after a x4500 to
x4540 upgrade.
In our case the the spares were in a separate data pool so the recovery
procedure we developed was relatively easy to implement as long as downtime
could be scheduled.
You may be able to tweak the procedure
