- The next problem is the fact that device files may be different on different nodes. The biggest problem is the Instance number of the interface the disk is connected to. Some administrators spend lots of time and effort to make the Instance numbers of all corresponding devices on a machine the same. That's fine by me if you want to take that route; see how we do it in Chapter 4, "Advanced Peripheral Configuration" (Rebuilding the ioinit File to Suit Your Needs). If you aren't going to spend all your time doing that, then you need to identify which disks are connected to which interfaces. You will need to work this out for all nodes in the cluster. See the example in Figure 25-2.
Figure 25-2. Identifying shared disks.
What we have is a single disk, dual-pathed from two hosts . In systems with lots of disks and multiple paths, e.g., through a SAN, you may have four paths per disk and possibly hundreds of disks. This example goes to show how you would identify which paths are " related " to a particular disk. Just looking at the device files will not show you much. Using a command like diskinfo won't yield much information either. We need to go back to our understanding of the layout of an LVM disk. At the beginning of a disk, we have the 8KB header used to point to the boot area. We then have the PVRA . The first element of the PVRA is an LVM Record, which identifies this disk as an LVM disk. The LVM Record is 8 bytes in size . So take 8KB + 8 bytes = 8200 (2008 in hex) bytes. If we read from that location, we find four interesting numbers in the PVRA ; the CPU-ID , the PV-ID , the CPU-ID (again) and the VG-ID . If we were to read this information from any of the device files, we should see exactly the same information. I would use the following command to do this:
# echo "0x2008?4X" adb /dev/dsk/cXtYdZ
adb moves to the prescribed address and prints four integers; in my case, I display them in hex (the reason for using hex will become apparent). In fact, if you look at the output below, I have run just that command on my first node, hpeos001 :
root@hpeos001[] # echo "0x2008?4X" adb /dev/dsk/c12t0d1 2008: 77A22A2C 3C9DFCD9 77A22A2C 3C9DFCD6 root@hpeos001[] # echo "0x2008?4X" adb /dev/dsk/c13t0d1 2008: 77A22A2C 3C9DFCD9 77A22A2C 3C9DFCD6
If we look at the output from the commands run from the other node, hpeos002 , the output should be the same.
root@hpeos001[] # echo "0x2008?4X" adb /dev/dsk/c9t0d1 2008: 77A22A2C 3C9DFCD9 77A22A2C 3C9DFCD6 root@hpeos001[] # echo "0x2008?4X" adb /dev/dsk/c10t0d1 2008: 77A22A2C 3C9DFCD9 77A22A2C 3C9DFCD6
Theses are the two nodes as shown in Figure 25-2. As you can see, the relevant fields match up regardless of which device file we look at. In a large, complex environment, this can help you visualize which device files are "related" to which disks.