DSF device files pointing to the same hardware path

[Susan Allen]

After a horrible MP replacement and reboot, my rx6600 has created the following device files:

/dev/rdisk/disk7 /dev/rdsk/c0t1d0
/dev/rdisk/disk8 /dev/rdsk/c0t0d0
/dev/rdisk/disk7_p1 /dev/rdsk/c0t0d0s1
/dev/rdisk/disk7_p2 /dev/rdsk/c0t0d0s2
/dev/rdisk/disk7_p3 /dev/rdsk/c0t0d0s3
/dev/rdisk/disk8_p1 /dev/rdsk/c0t0d0s1
/dev/rdisk/disk8_p2 /dev/rdsk/c0t0d0s2
/dev/rdisk/disk8_p3 /dev/rdsk/c0t0d0s3
/dev/rdisk/disk9 /dev/rdsk/c1t0d0
/dev/rdisk/disk9_p1 /dev/rdsk/c1t0d0s1
/dev/rdisk/disk9_p2 /dev/rdsk/c1t0d0s2
/dev/rdisk/disk9_p3 /dev/rdsk/c1t0d0s3

What I don't understand is the /dev/rdisk/disk7 is "mapped" to c0t1d0, but all the "sub-sections" are "mapped" to c0t0d0, which are the same as /dev/rdisk/disk8.

BTW - disk9 is the "secondary" in my mirrored pair, and it looks normal.

Any clues would be appreciated ...

- Susan

[Steven E. Protter]

Shalom Susan,

Welcome to 11.31 built in multipathing.

ioscan -m dsf

ioscan -m hwpath

These two commands will show you which disks are actually the same disks and hopefully clear up the confusion.

SEP

[Susan Allen]

Still confused ..

Here's the ioscan -m dsf output:
/dev/rdisk/disk7 /dev/rdsk/c0t1d0
/dev/rdisk/disk8 /dev/rdsk/c0t0d0
/dev/rdisk/disk7_p1 /dev/rdsk/c0t0d0s1
/dev/rdisk/disk7_p2 /dev/rdsk/c0t0d0s2
/dev/rdisk/disk7_p3 /dev/rdsk/c0t0d0s3
/dev/rdisk/disk8_p1 /dev/rdsk/c0t0d0s1
/dev/rdisk/disk8_p2 /dev/rdsk/c0t0d0s2
/dev/rdisk/disk8_p3 /dev/rdsk/c0t0d0s3

Here's a lssf of three of the "device files"
lssf /dev/rdsk/c0t1d0
sdisk card instance 0 SCSI target 1 SCSI LUN 0 section 0 at address 0/4/1/0.0.0.1.0 /dev/rdsk/c0t1d0
lssf /dev/dsk/c0t0d0
sdisk card instance 0 SCSI target 0 SCSI LUN 0 section 0 at address 0/4/1/0.0.0.0.0 /dev/dsk/c0t0d0
lssf /dev/dsk/c0t0d0s1
sdisk card instance 0 SCSI target 0 SCSI LUN 0 section 1 at address 0/4/1/0.0.0.0.0 /dev/dsk/c0t0d0s1



so, disk7 = /dev/c0t1d0, which is "target 1", but disk7_p1 = /dev/c0t0d0s1, which is "target 0", which matches disk8_p1, which is only "target 0".

I thought 11.31 only assigned one "agile" DSF to a path, not two.

[Armin Kunaschik]

Is it possible, that you have some leftover from the previous setup?
If you don't remove device files before you remove the device, and reboot, the old device files will stay in the filesystem.
BTW: This is the case in all HP-UX versions!
So your disk7_p* are actually "ghost" partitions.
Try removing all disk devices and recreate them:
rm /dev/dsk/*; rm /dev/rdsk/*; rm /dev/disk/*; rm /dev/rdisk/*; insf -e
This works while the system is running...

My 2 cents,
Armin

PS: Please assign points!

[Hasan Atasoy]

hi ;


what about ioscan -s


Hasan

[Susan Allen]

Yes, it's possible these device files are left over from a previous reboot. However, the most confused is /dev/disk/disk7. Here's an output from a lvlnboot -v, which is referencing the /dev/disk/disk7_p2 device file.

# lvlnboot -v
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/disk/disk7_p2 -- Boot Disk
/dev/disk/disk9_p2 -- Boot Disk
Boot: lvol1 on: /dev/disk/disk7_p2
/dev/disk/disk9_p2
Root: lvol3 on: /dev/disk/disk7_p2
/dev/disk/disk9_p2
Swap: lvol2 on: /dev/disk/disk7_p2
/dev/disk/disk9_p2
Dump: lvol2 on: /dev/disk/disk7_p2, 0


An ioscan -s does show stale entries, but only on the fibre cards, not the internal drives.

Also, here's the output from a setboot -v command:

setboot -v
Primary bootpath : 0/4/1/0.0x500000e012cb69f2.0x0 (/dev/rdisk/disk8)
HA Alternate bootpath : 0/4/1/0.0x500000e012cb69f2.0x0 (/dev/rdisk/disk8)
Alternate bootpath : 0/4/2/0.0x500000e012b16102.0x0 (/dev/rdisk/disk9)


Which implies that /dev/rdisk/disk8 is the "primary" path, not /dev/rdisk/disk7, which is listed in the lvlnboot -v ....

S

[Armin Kunaschik]

Hm... this looks really messy.
I'd suspect that disk7 comes from the lvmtab.
Is it possible to "vgextend vg00 /dev/disk/disk8_p2" and then remove disk7_p2?
disk8_p2 should appear as another PV path...
If this is not working, you should consider repairing (recreating) vg00 with vgscan. See the vgscan manpage for detail!

My 2 cents,
Armin