How to associate devices to disks?

[Jim Lahman_1]

Reviewing my sys$devices.dat file:

[Port CGLHD1$PKA]
Allocation Class = 10

[Port CGLHD1$PKB]
Allocation Class = 10

[Port CGLHD1$PKC]
Allocation Class = 10

[Port CGLHD1$DQA]
Allocation Class = 10

[Port CGLHD1$DQB]
Allocation Class = 10

and my disks

DSA0: Mounted 0 CGLHD1SYS 264391050 579 1
$1$DGA100: (CGLHD1) Mounted 0 HDGLDAT1 464596000 22 2
$1$DGA200: (CGLHD1) Mounted 0 PRDDSK 75831800 189 2
$1$DGA300: (CGLHD1) Mounted 0 HDGLODS5 454105950 541 2
$10$DKA0: (CGLHD1) ShadowSetMember 0 (member of DSA0:)
$10$DKA100: (CGLHD1) ShadowCopying 0 (copy trgt DSA0: 56% copied)

How do I know which device goes to which disk? A sh dev/full does not show me the device in which the disk's device.

Thanks,
Jim

[Steven Schweda]

I don't have a SYS#SYSTEM:SYS$DEVICES.DAT, so
what do I know? But I'd expect your DKA
disks to be connected to the PKA port device.
For a hint as to what PKA is, for example:
SHOW DEVICE /FULL PKA

Around here (XP1000), the DQA and DQB things
are the IDE ports. SHOW DEVICE /FULL DQ

I'm guessing that the DGA disks are fibre
channel disks, about which Google knows more
than I.

> How do I know which device goes to which
> disk?

Huh? What are you calling a "device", and
what a "disk"? Disks _are_ devices.

> A sh dev/full does not show me the device
> in which the disk's device.

Huh?

Perhaps you should post the confusing output
from "sh dev/full" and re-phrase your
complaint.

[Robert Brooks_1]

My guess is that whoever created your sys$system:sys$devices.dat file is a bit confused. The inclusion of the IDE drives (the "DQ" devices) is completely unnecessary; the only buses that should be listed there are any buses that can be shared between two or more nodes. We do not support sharing of IDE buses. While there is no harm in that listing, it may lead to confusion.

Also, fibre channel devices are always in allocation class 1, in case you are wondering how those "$1$" devices snuck in there, since you appear to want everything in allocation class 10.

Finally, you appear to have a single shadow set (DSA0), where the members are $10$DKA0: and $10$DKA100).

As Steven said, it's not clear what exactly you mean by "devices" and "disks". Could you try to rephrase the question so we could understand a bit better?


-- Rob (VMS Engineering)

[Martin Vorlaender]

Robert,

>>>
The inclusion of the IDE drives (the "DQ" devices) is completely unnecessary; the only buses that should be listed there are any buses that can be shared between two or more nodes. We do not support sharing of IDE buses.
<<<

I'd guess it's not so much about sharing devices, but about separating. If you have a node allocation class (that is the same on all nodes connected to a shared bus), you'd need port allocation classes to make e.g. the DQA0 devices of different nodes distinguishable. Though I'd prefer to use a port allocation value of 0, you could use different values for each node here.

cu,
Martin

[Jim_McKinney]

I'd like to echo what Martin has said. Inclusion of the local IDE drives in SYS$DEVICES.DAT is to eliminate confusion in the lock manager. If the devices have exactly the same names (as might occur with a non-zero allocation class) then VMS will attempt to generate locks with the same names for each of them when they're used. If they're used simultaneously in a cluster then VMS becomes "confused". (Been there, done that - simultaneous nightly jobs on 3 cluster nodes each making image copies of a shared system disk to their own private, and unmounted, local drives with the same device names produced "interesting" results as the mounts and dismounts overlapped.)

[Jim Lahman_1]

Here's what precipated this question. Since we are 24/7 operation and currently in an outage, I wanted to shadow the system disk on both nodes in my cluster. Should be simple enough.

So, I set up the proper sysgen parameters, setting shadowing to 2 and shadow_sys_disk to 1. I ran cluster$config to define the allocation class as 10 which I noticed changed the sys$system:modparams.dat file. I performed an autogen. When the system, CGLHD1, rebooted, I got a bug check. Whoa!

So, I spent some time reading the topics in the forum and discovered a file existed called sys$devices.dat. I looked at the file and noticed that the allocation classes for all devices were set to 0; cluster_config did not alter this file (don't know if it was supposed to or not).

Seeing that devices PKA, PKB, PKC were listed in this file, I wanted to know which device that system disk was inserted. Was it PKA? PKB? PKC? I did a sh dev/full dkb0: and it did not reveal that information. Neither did sh dev/full pka reveal this information? So, I just set the allocation class for pka, pkb, pkc to 10. When I rebooted, the the system disk changed from CGLHD1$DKB0 to $10$DKA0. But, the DQ devices were still prefixed with CGLHD1. So, for esoteric reasons, not technical reasons, I changed the allocation class for the DQ devices to 10.

Once the allocation classes were set properly in sys$devices.dat, I set the sysgen shadowing parameters so that I can shadow the system disk. I rebooted with success. The system disk is now shadowed.

However, the question still remains. How would I correlate the devices listed in sys$devices.dat to the actual disks by using vms commands? Or, do I have to use commands at the boot prompt?

Jim

[Martin Vorlaender · Accepted solution]

Jim,

>>>
... the system disk changed from CGLHD1$DKB0 to $10$DKA0.
<<<

That is correct. As soon as you configure an allocation class, the controller letter ("B" in your example) is changed to "A".

>>>
However, the question still remains. How would I correlate the devices listed in sys$devices.dat to the actual disks by using vms commands? Or, do I have to use commands at the boot prompt?
<<<

With the (port) allocation classes set like you did (10 on PKA, PKB, and PKC), you would indeed not be able to tell if a device $10$DKA100 was SCSI ID 1 on controller A, B, or C. Which is why I'd recommend a port allocation class of 0 (or at least different ones) on all non-shared busses.

HTH,
Martin

[Robert Brooks_1]

I'd guess it's not so much about sharing devices, but about separating. If you have a node allocation class (that is the same on all nodes connected to a shared bus), you'd need port allocation classes to make e.g. the DQA0 devices of different nodes distinguishable. Though I'd prefer to use a port allocation value of 0, you could use different values for each node here

---

Oh, I always give my nodes their own allocation class, so I never run into the situation you describe. Is there any reason why you use the same allocation class for more than one node? I usually make the allocation class the same as the SYSn root number on the system disk, and try to make that value the DECnet node number, if I have that flexibility.

-- Rob

-- Rob

[Martin Vorlaender]

Rob,

>>>
Is there any reason why you use the same allocation class for more than one node?
<<<

The scenario where you have to have the same (port) allocation class for more than one cluster member is when you have a shared SCSI bus cluster. If each node on the cluster would have its own alloclass, devices on the shared SCSI bus would have different names on different nodes - not a desirable situation.

cu,
Martin

[Jim Lahman_1]

I want to thank everyone that helped me to understand allocation classes and shadowing.

I just shadowed the system disk on CGLHD2, the other node on the 2-node cluster using an allocation class of 20. There was just one gotcha I ran into, I attempted to boot the shadowed system disk with SHADOW_SYS_UNIT set to 0, which is the default and what is in use on CGLHD1. This led to a bug check.

So, I set SHADOW_SYS_UNIT to 20. CGLHD2 then booted fine.

My disks now look like this:

DSA20: Mounted 0 CGLHD2SYS 263135675 575 1
$1$DGA100: (CGLHD2) Mounted 0 HDGLDAT1 461022100 23 2
$1$DGA200: (CGLHD2) Mounted 0 PRDDSK 76554225 189 2
$1$DGA300: (CGLHD2) Mounted 0 HDGLODS5 454072176 574 2
$10$DKA0: (CGLHD1) Online 0 (remote shadow member)
$10$DKA100: (CGLHD1) Online 0 (remote shadow member)
$10$DQA0: (CGLHD1) Online 0
$20$DKA0: (CGLHD2) ShadowSetMember 0 (member of DSA20:)
$20$DKA100: (CGLHD2) ShadowCopying 0 (copy trgt DSA20: 11% copied)
$20$DQA0: (CGLHD2) Online 0
$20$DQA1: (CGLHD2) Offline 1
$20$DQB0: (CGLHD2) Offline 1
$20$DQB1: (CGLHD2) Offline 1

[Jim Lahman_1]

I was confused on how allocation classes work in regards to shadowing a system disk. Not only was I able to get help on this, but also an understanding on how to setup an allocation class for a node and an entire cluster.

[Robert Brooks_1]

Is there any reason why you use the same allocation class for more than one node?
<<<

The scenario where you have to have the same (port) allocation class for more than one cluster member is when you have a shared SCSI bus cluster. If each node on the cluster would have its own alloclass, devices on the shared SCSI bus would have different names on different nodes - not a desirable situation.

---

Yeah, but that's not my question. I am quite aware of when one needs to use port allocation classes. I'm asking why one would set the SYSGEN param ALLOCLASS to be the same on all nodes. While that used to be a requirement for MSCP serving (the node and controller needed to have matching allocation classes), that restriction was removed quite some time ago.

My point (with which some will disagree) is that port allocation classes should only be used when needed, as I've seen it cause a fair amount of confusion in places where its use didn't really help.

That's why I recommend separate ALLOCLASS values across the cluster and creating PACs only for (potentially) shareable SCSI buses.

-- Rob (a VMS Engineer who has spent a fair amount of time looking at the PAC code)