Primary vs Current Disk Paths

[Jack Trachtman]

A "SHOW DEV FULL san-disk-name" will show one physical path as CURRENT and also show one path (possibly the same path) as PRIMARY.

What's the definition of PRIMARY and why would this info be useful to me? Doesn't CURRENT mean that all I/O (data + cmds) go across that path? Thanks

[Arch_Muthiah]

Jack,

If the device has multiple I/O paths, then primary path is the first one found by OpenVMS at I/O configuration.
And the current path is the one in use now.

A path can be set manually via
$ SET DEVICE/PATH=device-path/SWITCH
A path can be changed automatically by a mount verification.

Starting with OpenVMS V7.2-2 (or earlier with VMS721_SYSV0100 or VMS721H1_SYS-V0600) mount verification attempts the current path first.

Before OpenVMS 7.2-2 mount verification attempts the primary path first

Starting with OpenVMS V7.3-1, mounting a multipath disk can result in a path change.

Archunan

[Phillip Thayer]

Jack,

The idea of which IO patch to the SAN is the current path or Primary path is useful when trying to look at balancing IO across multiple Physical IO connections to the SAN. If you have a large number opf drives connected to the SAN with multiple IO paths you can use the SET DEVICE/PATH=io-path-name/SWITCH to balance the IO across the multiple physical connections. If you do not do the SET DEVICE/PATH= command then all of your SAN drives will end up using the same IO path to the SAN and you create a possible IO bottleneck situation.

As for the Primary path it is simply the first connection that the H/W finds when connecting to the SAN.

Phil

[Robert Brooks_1 · Accepted solution]

The previous replies are mostly correct, except for . . .

-------------
If you do not do the SET DEVICE/PATH= command then all of your SAN drives will end up using the same IO path to the SAN and you create a possible IO bottleneck situation.
--------------

Starting with V7.3-1, there is a very lightweight attempt made to spread out the current paths at boot time over all available paths. We keep count of how many devices have their current path set to any given path, and try to keep the number of current paths equally spread over the given paths.

This is a one-time balancing act, however, and over time, it is possible that an imbalance may happen. Also note that there can be many devices doing no I/O; the fact that their path is current doesn't really mean that any load is generated on that path.

As earlier replies have correctly stated, the primary path is merely the first path discovered. In retrospect, it probably would have been better never to have made that
distintion user-visible, since it has caused a fair amount of confusion and generated a lot of questions.


-- Rob (multipath engineer)

[Robert Atkinson]

Jack - the attached document may help you understand this a little more.

Rob.

[Peter Zeiszler]

We use the SET DEVICE/PATH command whenever we are preparing to patch a switch or work on the SAN controllers. This gives the customer confidence that the alternate path is still valid and working properly and that we are able to failover to the alternate paths.

We also manually watched the SAN switches for load for the VMS systems and moved some of the heavy I/O devices to use alternate switches. The disks then try to stay on that path. If I have a san switch fail I know it will automatically use the other path for continuous access.

[Rob Young_4]

Like the previous poster, for switch upgrades/
replacements - we too make sure all paths
are valid. Extraneous work for sure but
you can't always trust things (don't ask).

Rob ... what I would like to see is in
addition to intelligent load balancing
(made mention in other posts in other
forums), is a periodic automatic switch to
ensure IO can go down all paths. What I mean
is if a device had 3 IO paths it would periodically test the others. As it is, you
see current path, all IO has gone down the
current path and you have no indication that
the other paths with 0 IO are valid paths, hence
the need to switch to those paths prior
to a switch upgrade.

I trust VMS path switching. What I would
like to do is point out that IO has gone
down all paths, therefore all paths are
valid therefore this extraneous work of
switching paths is over-kill - forget
about it...

Thanks,
Rob

[Volker Halle]

Rob Y.,

the multipath poller should be polling each path from time to time (see HELP SET DEV/POLL), so you should become aware (via OPCOM messages), if a path is not working.

Volker.

[Robert Atkinson]

Rob - I agree with your conclusion, and we no longer attempt to force paths, as VMS just switches them itself anyway.

The document does help to give an insight into how paths work, though.

Rob.

[Jack Trachtman]

"In retrospect, it probably would have been better never to have made that
distintion user-visible, since it has caused a fair amount of confusion and generated a lot of questions"

I guess that answers my question - no
really useful info for me in knowing
what the Primary path is/was.

Thanks all