How to know two device file pointing to same LUN

[Redhat]

Say you have 4 devices c4t1d1, c4t1d2, c4t1d3 and c4t1d4 with alternate links of c5t1d1, c5t1d2, c5t1d3 and c5t1d4.

My query is how to know c4t1d1 & c5t1d1 refer to the same LUN in the first instances priar to create VG from ioscan output.

Thanks in advance

[Sandman!]

That's possible by running cmds on the backend array. For example in the case of XP storage subsystems the CU:LDEV combination points to a unique LUN on the entire array. This info can be obtained either by running vendor supplied utilities like "xpinfo" or by querying the storage array thru the Service Processor.

~hope it helps

[A. Clay Stephenson]

That can be rather easy or difficult depending upon the type of array. Most arrays have utilities that will tell you this but there is a general technique that can be used --- but you might destroy data if you choose the wrong devices --- so know that the device nodes that you are accessing are not in use by this system or any other system.

1) Safe in all cases:
compare the diskinfo -v /dev/rdsk/cXtYdZ outputs of the suspected primary and alternate device nodes. If the outputs are identical then the two MIGHT be the same physical device/LUN. If they differ they cannot refer to the same LUN.

2) Still safe in all cases:
We are going to read 10MiB of data and compare the output.
dd if=/dev/rdsk/c4t1d1 of=/var/tmp/f1 bs=1024k count=10
dd if=/dev/rdsk/c5t1d1 of=/var/tmp/f2
bs=1024k count=10
cksum /var/tmp/f1 /var/tmp/f2

If the checksums are identical then the two devices MIGHT refer to the same LUN; if not they cannot.

3) Now it's dangerous and only if 1) and 2) have tested true. Write a small script which will capture a string argument supplied on the command line; it must be unique to this LUN. Loop echoing your string until 1024 characters have been written to a file. Now dd this file like this:
dd if=myfile bs=1k count=1 of=/dev/rdsk/c4t1d1
Now read it back using the alternate link:
dd if=/dev/rdsk/c5t1d1 bs=1k count=1 of=myfile2
cksum myfile1 myfile2
If the checksums are identical, you have found the links.

[Redhat]

Thanks Stephenson .I understood that the only way to find out the alternative link is though the storage software where there are 100's of LUN . From OS level it is really a trial and hit method .But there should be some thing by studing ioscan -funC fc; ioscan -funC fcp;ioscan -fnC ext_bus output we can identify the primary and alternative link.

[A. Clay Stephenson]

But there should be some thing by studing ioscan -funC fc; ioscan -funC fcp;ioscan -fnC ext_bus output we can identify the primary and alternative link.

Why should this be so? The only part of the cXtYdZ equation over which the host has any control is the cX part. The SCSI ID (tY) and LUN (dZ) is strictly data that are presented to the host computer; the host computer has no control over those parameters. Most UNIX boxes will accept LUN's from any disk array manufacturer as long as the arrays play by the rules.

[Redhat]

I apprecite all your effort.i have attached the ioscan -fnC disk output for a practical senario from where we have to find out the no.s of actual disks present and what are the primary & alternative link .we don't have any access to the storage console.Need all your thougths ..

[Matti_Kurkela]

Update to HP-UX 11i v3 :-)
It has the ioscan options to display the WWID numbers of each FC link. By them, you can identify the multiple links to the same LUN.

Thing is, at that point the OS will have already noticed the same thing and automatically set up load-balancing multipathing for it, so you may not need to care :-)

With HP-UX 11.23 or older, on the /dev/dsk/c*t*d* level, there simply *isn't* any "primary" or "alternate" links. All links are the same, and this level just does not know or care that two or more links might point to the same data.

If your array puts some unique identifier to the SCSI Product ID/Vendor ID fields of each LUN so that LUNs can be identified from that, you could run commands like "diskinfo -v /dev/rdsk/c4t1d1" to identify the LUNs without vendor-specific tools.

When you're creating or importing a VG, the LVM layer will notice that some of the PVs have identical PVIDs. At this point, one of the links will be named as "primary" and the rest as "alternates". PVIDs are created and written to the disk when you run "pvcreate" to a LUN.

One way to confirm that two links point to the same LUN would be to run "pvdisplay" for each link before doing "pvcreate" to confirm that there is no LUN with a PV structure yet.
Then, run "pvcreate /dev/rdsk/c4t1d1", and after that, "pvdisplay /dev/dsk/c5t1d1". If the link c5t1d1 got turned into a valid PV when you pvcreate'd the link c4t1d1, you know these two must point to the same LUN.

Another "lazy man's way": create the VG using just one set of links. Then vgexport it _using the -s option_. Recreate the /etc/vg*/group file and reimport the VG using the command "vgimport -s -m mapfile -v vgname". Note that you don't list the PVs in this command at all.

The vgimport command will read the VGID from the map file, and then will search for that VGID from the beginning of every disk that is not associated with an active volume group. It will detect *all* PVs of that VG and *all* links to them automatically. Of course, if you have a huge number of LUNs presented to the host, it may take a while.

The expected result would be that the numerically first devices, i.e. c4t*d* devices in your case would become primary links and c5t*d* as alternate links. If this is not what you want, you must then shuffle them manually.

MK

[marie-noelle jeanson]

Hi,

Note that with 11i v3, the LUN WWID is displayed by the scsimgr command. This will allow I think to verify what LUN WWID a dsf name is associated with and therefore to compare 2 WWIDs for 2 dsf names.

Marie

[Redhat]

Thanks for all your valued feedback.