Discussion: Device special file changed for unknown reason.

[stephen peng]

Guys,

There was a situation in my rx2660 box. The IR volume dsf used to be c1t0d0, and under some circumstances which I was not aware of, the dsf changed to c9t1d0; in fact, all disk dsfs changed, like a HSV200 volume changed from c2t0d1 to c1t0d0, and all HW path remained unchanged!

1, what would cause these changes? You could offer every possibility.

2, would OS boot under such situation? Why? and if it could, what problem would it cause?

Regards

Stephen

[Ken Grabowski]

The CTD numbers are directly related to the controller (FCA) and SCIS addresses.  If the addressing at the storage array changed, then so will the CTD.  Have you been doing a storage migration?   Have any of your VG/LV's had an issue? What operating system are you using?

[stephen peng]

Hi Ken,
I don't think there was a migration, maybe just replacing a fault local hard drive or so. Of course all VGs had issue cause all the dsf changed. It was an HP-UX 11.23 box.

regards
Stephen

[Ken Grabowski]

Have you checked with your storage team? Have you recovered your volume groups?

[Ken Grabowski]

Steven,

HSV volumes are SAN attached storage.  Normally you would have multiple paths to each disk.  Anywhere from two to four in most environments.  Were your volume groups built with alternate paths, or only the primary?  Did a fiber path go away? 

What does your vgdisplay -v show?

Run  "ioscan -funC fc" to get your fiber controller card address and then check their status with "fcmsutil /dev/fcd#"

A properly configured volume group with SAN attached drives should have a primary disk path and an alternate path for each fiber path.  The CTD address would normally change for each path based on the FC address.

[stephen peng]

Hi Ken,

1,Just check attached file you will see the difference,

2,I have ajusted VGs' configuration and they are alright now.

3, It was interesting that it seemed that HSV volume c2t0d0 took over dsf c1t0d0 and IR volume had to use c9t0d0

4, why could OS boot with c9t0d0?

Regards

Stephen 

[Ken Grabowski]

All the SCSI addresses remained the same for the SAN disk. I would check with the SAN storage team and see if the WWN's changed or anything else that could affect the controller address.

I've never seen the internal disk controller address change, but I could guess that if a change in the SAN caused a conflict with the internal controller the OS might cause the change!  But if you have a support contract I would suggest you open a ticket and find out from HP how it could happen.

The boot is a simple answer. The setboot is configured with the hardware path not the CTD address. So the boot goes to 0/1/1/0.0.0.0.0, not c1t0d0 or c9t0d0.

[Torsten.]

Really strange.

All the instance numbers have changed.

Did somebody manipulate the ioinit database?

[stephen peng]

Hi Torsten,
I don't think no one would know how to do this manipuation, most possibly, hard drive replaced; maybe one of the two san switch was replaced, it is a cluster enviroment, and the other box remained nothing changed.

regards
Stephen

[Ken Grabowski]

If the World Wide Name WWN changes on the SAN disks it will change the C value of the device path. Replacing a local disk will affect the IR Volume at the SAS controller level but will not change the device path at all.  If changes occur at the SAN array or fabric router level, they need to be planned in advance.  Volume group map files should be created. Volume groups removed (exported) and systems shutdown until the change is completed. After the change, then volume groups can be recreated and imported from the map files. 

These kinds of changes should never occur unannounced or unplanned. The affect of changing without the proper planning  are system crashes and missing disks, like you just experienced.