Hi Ryan,
What events lead up to this situation? I've seen a similar problem when
a system upgrade caused the controller numbers of the spares to change.
In that case, the workaround was to export the pool, correct the spare
device names, and import the pool. I'm not sure if this workaround
applies to your case. Do you know if the spare device names changed?
My hunch is that you could export this pool, reconnect the spare
devices, and reimport the pool, but I'd rather test this on my own pool
first and I can't reproduce this problem.
I don't think you can remove the spares by their GUID. At least,
I couldn't.
You said you tried to remove the spares with zpool remove.
Did you try this command:
# zpool remove idgsun02 c0t6d0
Or this command, which I don't think would work, but you would
get a message like this:
# zpool remove idgsun02 c0t6d0s0
cannot remove c0t6d0s0: no such device in pool
Thanks,
Cindy
On 07/08/10 14:55, Ryan Schwartz wrote:
I've got an x4500 with a zpool in a weird state. The two spares are listed
twice each, once as AVAIL, and once as FAULTED.
[IDGSUN02:/opt/src] root# zpool status
pool: idgsun02
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
idgsun02 ONLINE 0 0 0
raidz2 ONLINE 0 0 0
c0t1d0 ONLINE 0 0 0
c0t5d0 ONLINE 0 0 0
c1t1d0 ONLINE 0 0 0
c1t5d0 ONLINE 0 0 0
c6t1d0 ONLINE 0 0 0
c6t5d0 ONLINE 0 0 0
c7t1d0 ONLINE 0 0 0
c7t5d0 ONLINE 0 0 0
c4t1d0 ONLINE 0 0 0
c4t5d0 ONLINE 0 0 0
raidz2 ONLINE 0 0 0
c0t0d0 ONLINE 0 0 0
c0t4d0 ONLINE 0 0 0
c1t0d0 ONLINE 0 0 0
c1t4d0 ONLINE 0 0 0
c6t0d0 ONLINE 0 0 0
c6t4d0 ONLINE 0 0 0
c7t0d0 ONLINE 0 0 0
c7t4d0 ONLINE 0 0 0
c4t0d0 ONLINE 0 0 0
c4t4d0 ONLINE 0 0 0
spares
c0t6d0 AVAIL
c5t5d0 AVAIL
c0t6d0 FAULTED corrupted data
c5t5d0 FAULTED corrupted data
errors: No known data errors
I've been working with Sun support, but wanted to toss it out to the community
as well. I found and compiled the zpconfig util from here:
http://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSGuids and found that the
spares in question have different GUIDs, but the same vdev path:
spares[0]
type='disk'
guid=7826011125406290675
path='/dev/dsk/c0t6d0s0'
devid='id1,s...@sata_____hitachi_hua7210s______gtf000pahjmlxf/a'
phys_path='/p...@0,0/pci1022,7...@1/pci11ab,1...@1/d...@6,0:a'
whole_disk=1
is_spare=1
stats:
state=7
aux=0
...
spares[1]
type='disk'
guid=870554111467930413
path='/dev/dsk/c5t5d0s0'
devid='id1,s...@sata_____hitachi_hua7210s______gtf000pahj5nlf/a'
phys_path='/p...@1,0/pci1022,7...@4/pci11ab,1...@1/d...@5,0:a'
whole_disk=1
is_spare=1
stats:
state=7
aux=0
...
spares[2]
type='disk'
guid=5486341412008712208
path='/dev/dsk/c0t6d0s0'
devid='id1,s...@sata_____hitachi_hua7210s______gtf000pahjmlxf/a'
phys_path='/p...@0,0/pci1022,7...@1/pci11ab,1...@1/d...@6,0:a'
whole_disk=1
stats:
state=4
aux=2
...
spares[3]
type='disk'
guid=16971039974506843020
path='/dev/dsk/c5t5d0s0'
devid='id1,s...@sata_____hitachi_hua7210s______gtf000pahj5nlf/a'
phys_path='/p...@1,0/pci1022,7...@4/pci11ab,1...@1/d...@5,0:a'
whole_disk=1
stats:
state=4
aux=2
...
I've exported/imported the pool and the spares are still listed as above.The regular
'zpool remove idgsun02 c0t6d0s0' (and c5t5d0s0) also do not work, but do not produce any
error output either. This sounds remarkably like
http://bugs.opensolaris.org/bugdatabase/view_bug.do;?bug_id=6893472 but as I said, the
export/import does not correct the issue. Any suggestions on how I can remove the
"FAULTED" spares from the pool? Can I use the GUID with zpool remove somehow?
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
