LOCKS set maintained by $MOU for the system (boot) device

[Ruslan R. Laishev]

Hello All!

Is there someone wha can help me to get/understand an information about: what is set of locks is created and maintained for the disk volume by MOUNT?
Is there some differences in lock/resources content between volumes on PKA (SCSI), PNB (CI+HSJ), PG/FG (EVAxK) ?

[Hoff]

The MOUNT, DISMOUNT and RMS-level lock use is listed in the back of the Internals and Data Structures Manaual; in the IDSM.

There's the volume label lock, the mount device lock, the volume allocation lock, the volume-blocking lock, among various others.

These and other locks can be viewed using SDA, among available tools.

The basic locks are the same across the various devices; the port and even the class drivers are not particularly involved in locking. There are second-level coordination issues around SAN-level mechanisms that the FC SAN giblets can and do get involved with. These are not generally host-visible.

What might you be looking to do? (I'm not looking to re-key large tracts of the IDSM into this little text box right now.) I might guess what you are attempting here, but...

Stephen Hoffman
HoffmanLabs LLC

[Ian Miller.]

$ DEFINE SHOW$DEBUG 1
$ SET TERMINAL/WID=132
$ SHOW DEVICE devicename

will show you lock details. The File Systems Internals book has a useful section on locks.

[John Gillings]

Ruslan,

I'm assuming you understand the distinction between a RESOURCE and a LOCK.

SHOW$DEBUG might help, but it doesn't give you the resource names. SDA helps a bit, but I don't know of a way to look for resource names by wildcard. About the best you can do is

SDA> SET OUTPUT resourcenames.txt
SDA> SHOW RESOURCE/BRIEF
SDA> SET OUTPUT SYS$OUTPUT

This will probably be a large(!) file which you can SEARCH. Make sure you use /BRIEF so the resource name isn't wrapped.

Note that very few of the resource names contain the physical device name - I think the only one relevant to MOUNT is the mount device lock SYS$_. All the other resource names are based on the volume label. See F11B$x and CACHE$x - this is a fairly good clue that they're independent of device technology.

Are you experiencing a problem which you believe to be related to differences you're asking about?

[Hein van den Heuvel]

As Ian already indicated... you gotta get the book if you really want to know.
The book being:
"Vms File System Internals - by Kirby McCoy"
http://www.amazon.com/Vms-File-System-Internals-VAX/dp/1555580564

Chapter 7 : "Serialization of File System Activity"

There is no differnce as to the driver/disk being used.

Any particular reason you are asking?
A hung process?
The most common issue we see is with highwater-marking and performing a non sequential write or a EOF attribute change causing 'everytthing else' to lock up.

Cheers,
Hein.

[Jon Pinkley]

Rusian,

Your subject indicates you are interested in the boot device.

Without knowing more about what you want to do, it is hard to know what synchronization mechanism is in play.

Specifically, there is a requirement to be able to do I/O with a device before it is mounted. That's at a very low level; $QIO IO$_PACKACK is called to set the volume valid bit, and then IO$_READLBLK can be issued to read data off the the device. It's been a long time since I did any of this stuff, long before VIOC or XFC, but my guess is that this bypasses any caching done by them, because they are file level caches, not LBN caches. What happens with third party caching products, I don't know. I do know there are warnings in the 7.3x realease notes about third party products and multipath devices.

And during the initial boot, the normal drivers aren't even used; instead the boot driver is used (it is also used to write the system dump file, at least that used to be the case 15 years ago).

So can you provide a bit more info about what you are wanting to do that requires knowlege about the locks being used by Mount?

If you are working with this level of stuff, you should have at a minimum:

OpenVMS AXP Internals and Data Structures V1.5 Hardcover, 1672 pg. 1994 ISBN 1-55558-120-X
plus the two paperback updates.

VMS File System Internals ISBN 1555580564 1990

If you are working with VMS Clusters, and want to know about locks used there

VAXCluster Principles ISBN 1555581129 1993

All are out of print. The VAXCluster book commands the most $$$

And if you are doing any system level programming, the VMS source listings are the most accurate documentation, once you know where to look.

May the Source be with you,

Jon

[Ruslan R. Laishev]

Hello, All!

Thanks for te response! I have to look to IDS an other VMS's internals.

The primary problem is the "good old" status "DIFVOLMNT, different volume already mounted on this device" during boot of Alpha and next BUGCHECK with the status.

I susspect that dirigng MOUNT of the sys$sysdevice a resourse value block is filled by data which describes a physical path to the volume on the HSJ/EVA storage. So, VMS at boot time cannot determine that the volume on the HSJ/EVA is the same.

[Ruslan R. Laishev]

Hello, All!

Thanks for the response! I have to look to IDS an other VMS's internals.

The primary problem is the "good old" status "DIFVOLMNT, different volume already mounted on this device" during boot of Alpha and next BUGCHECK with the status.

I susspect that dirigng MOUNT of the sys$sysdevice a resourse value block is filled by data which describes a physical path to the volume on the HSJ/EVA storage. So, VMS at boot time cannot determine that the volume on the HSJ/EVA is the same.

[Hein van den Heuvel]

Ruslan,

I assume you call it 'good old' because you googled for that code and found pages of relevant hits such as:

http://h71000.www7.hp.com/wizard/wiz_9685.html

Cheers,
Hein.

[Ruslan R. Laishev]

Hello, Hein!

Yes, my case is looks like you pointed.

[Volker Halle · Accepted solution]

Ruslan,

are you trying to understand or diagnose a PROCGONE - DIFVOLMNT problem ?

I've also recently seen this problem and scratched my head, whether this bugcheck is really necessary. I have not yet had the time and courage to further dig into this problem scenario.

It was a simple configuration with 2 nodes in a LAN-only cluster. No shared IO buses.

Node1 had Node2's system disk mounted.
When rebooting Node2, it crashed with PROCGONE R0=DIFVOLMNT.

After dismounting node2's system disk from Node1, Node2 could boot without a problem.

No wrong or changed volume labels and such.

Volker.

[Hoff]

Check the low-level settings in the SCBs for the volumes. There was a bug I slammed into a while back involving the OpenVMS Freeware. I'd replicated the Freeware disk volumes from one master disk, and had used SET VOLUME/LABEL to reset the volume labels. Unfortunately, MOUNT was looking at a field in the SCB that relabeling the volume had not adjusted, and this was resulting in duplicate volume errors during MOUNT operations. (IIRC, the error was DIFVOLMNT.) This was back around Freeware V5? (Yes, I reported it.)

[Volker Halle]

Ruslan,

I've tried to reproduce this problem. I seem to have left out a minor, but significant, action in my previous description:

Node1 had Node2's system disk mounted.

>>> Here I had booted Node2 STANDALONE (VAXCLUSTER=0) temporarily !

When rebooting Node2 into the cluster, it crashed with PROCGONE R0=DIFVOLMNT.

After dismounting node2's system disk from Node1, Node2 could boot without a problem.


So the fact, that Node2's system disk was still mounted from Node1 - disk was in HostUnavailable Mounted on Node1 while Node2 was not in the cluster - AND that Node2 mounted the disk STANDALONE temporarily, seems to have changed enough low-level data on the disk, that Node1 got the DIFVOLMNT error when booting into the cluster again.

Volker.

[Volker Halle]

Ruslan,

the code is in [MOUNT96]MOUDK2

Mount maintains a HASH value of certain fields (including Mount Time) inside the SCB on disk in the Lock Value Block of the Device Lock (SYS$_).

If the HASH value constructed by reading the SCB does not match the field in the lock value block, the DIFVOLMNT error is returned.

Volker.

[Jon Pinkley]

This usenet thread has some info, see Andy Goldstein's reply.

Thread "Another Question- Something about mapping F11BXQP?"

http://groups.google.com/group/comp.os.vms/browse_thread/thread/ff54db0336c8d1b3/c4e6149b3c4639a8?lnk=st&q=&rnum=2#c4e6149b3c4639a8

[Ruslan R. Laishev]

Thanks a lot to All reponders!

My respects!