Replaced FC drive in zpool, now can't get rid of old drive

Newsgroups	comp.sys.sun.admin
Date	2016-07-28 06:46 -0700
Message-ID	<ced67486-d558-4c4d-a552-c662b08202b7@googlegroups.com> (permalink)
Subject	Replaced FC drive in zpool, now can't get rid of old drive
From	Scott <spackard@gmail.com>

Show all headers | View raw

On a Solaris 10x64 server attached to an HP SmartArray (with 32 LUNs) I have two zpools, each using 16 LUNs.  The LUNs are presented via FC (they map 1:1 to HDDs in the HP box).  This was my attempt to let ZFS deal with raidz2 of two pools, rather than using the hardware RAID5 the HP box likes.

Multipathing is also done to the LUNs, so the device I deal with starts with /scsi_vchi/... (though /dev/rdsk and /dev/dsk exists at a lower layer for it).

I've had this running for a few years, then one of the HDDs died.
Googling (or, https://docs.oracle.com/cd/E23823_01/html/819-5461/gbbvf.html) says to take the zpool offline in order to do the HDD replacement, which seems absurd, so I didn't do that.  I deleted the old LUN (from the HP) and created a new one (from the HP), and when I did the new LUN has a new WWPN.

Next I had Solaris scan for and create new links to the LUN.
Then I did a zpool replace <pool> <old LUN> <new LUN>.
The pool is healthy, after about 24 hours of resilvering.

How do I get rid of the old LUN though?
format and luxadm probe shows it there, but it's not in mpathadm list LU.
If I luxadm probe , get the WWN of the B/O FC HDD, then
luxadm display <WWN> 2>&1 | less
I see ERROR: I/O failure communicating with /dev/rdsk/c5t<longnum>/d0s2

cfgadm -al doesn't show controllers higher than c2.

Regards, Scott

Back to comp.sys.sun.admin | Previous | Next — Next in thread | Find similar

Thread

Replaced FC drive in zpool, now can't get rid of old drive Scott <spackard@gmail.com> - 2016-07-28 06:46 -0700
  Re: Replaced FC drive in zpool, now can't get rid of old drive "DoN. Nichols" <BPdnicholsBP@d-and-d.com> - 2016-07-29 04:25 +0000

csiph-web