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?
--
Ryan Schwartz, UNIX Systems Administrator, VitalSource Technologies, Inc. - An
Ingram Digital Company
Mob: (608) 886-3513 ▪ ryan.schwa...@ingramdigital.com
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
