Stale LUN paths

[Mauro Livi]

Hi all,

I mistakenly posted this to the general servers discussion...this is probably a better place for it...anyway below is my issue.

We have an rx2800 i4 running HP-UX OS 11.31 which is connected to a 3Par array. We recently did an OS upgrade to our 3Par which was successful. During the 3Par upgrade, the nodes on the array had to be rebooted, and all was well.

However, when I checked on the HP-UX end, I noticed that when I look at the legacy DSF(s), I now have alternate paths to the LUNS that did not exist prior to the upgrade. For Example note the before/after results on the following ioscan:

BEFORE UPGRADE

ioscan -m dsf /dev/rdisk/disk131
Persistent DSF           Legacy DSF(s)
========================================
/dev/rdisk/disk131       /dev/rdsk/c10t3d2
                                 /dev/rdsk/c6t3d2
                                /dev/rdsk/c11t3d2
                               /dev/rdsk/c15t3d2

AFTER UPGRADE

ioscan -m dsf /dev/rdisk/disk131
Persistent DSF           Legacy DSF(s)
========================================
/dev/rdisk/disk131       /dev/rdsk/c10t3d2
                                 /dev/rdsk/c6t3d2
                                 /dev/rdsk/c11t3d2
                                 /dev/rdsk/c15t3d2
                                 /dev/rdsk/c21t3d2
                                 /dev/rdsk/c19t3d2
                                 /dev/rdsk/c17t3d2

Note that I now have 3 additional Legacy DSF(s) for this particular disk which didn't exist prior to the 3Par upgrade. Furthermore, if I do an ioscan on the devices, I see that these show as NO_HW as shown below, and again, prior to the upgrade this device did not exist (I have an ioscan from before the upgrade and the path/device below was non existant):

Class     I  H/W Path        Driver S/W State   H/W Type     Description
========================================================================
disk    159  0/0/0/7/0/0/0.13.0.1.0.3.2  sdisk   NO_HW       DEVICE       3PARdataVV
                            /dev/dsk/c17t3d2   /dev/rdsk/c17t3d2

This leads me to believe that these are stale alternate paths which were introduced at some point during the 3Par upgrade. They don't seem to hurt anything and our system is running normally.

However in the interest of best practices, I would like to get rid of these, so my questions are:

1) Anyone know how/why these alternate paths got created?

2) How do I get rid of them?

Any input is greatly appreciated.

Thanks

Mauro

[Torsten.]

likely they appear because of persistent ports during the upgrade, no change to agile device files, but a different path for legacy device files.

[Mauro Livi]

Thanks Torsten,

Any way I can get rid of them? I agree that there are no changes to the agile device files, it's just that those NO_HW kind of bug me (even though they're likely harmless enough).

Thanks

Mauro