[Info-vax] Error mounting system device after cluster creation

[Stephen Hoffman]

On 2019-07-08 14:39:13 +0000, Robert A. Brooks said:

> On 7/8/2019 8:40 AM, John E. Malmberg wrote:
>> On 7/7/2019 8:02 AM, Daniel Sundqvist wrote:
>> 
>>> According to my very limited knowledge there is this ALLOCLASS wich is 
>>> used to differentiate between devices in the cluster. If there is some  
>>> other relevant is beyond me right now ;)
>> 
>> ALLOCLASS is only needed if more than one system has a direct path to 
>> the storage.
> 
> Perhaps not relevant to this problem, but Host-Based Volume Shadowing 
> requires a non-zero ALLOCLASS.

Apropos of little, GUIDs were the Microsoft / EFI / UEFI approach which 
had several different uses, one of which avoids this particular 
configuration-detection mess.  Another use was the mess that was and is 
EFI boot aliases.  Not that OpenVMS plays particularly nicely with 
storage GUIDs, either.  Too easy to end up with duplicates. OpenVMS has 
been tussling with this whole area for many years, though. The GUIDs 
being uniquely-identifying data written onto the storage devices, 
rather than user-established hardware configuration data akin to the 
host and port allocation classes and that implicitly also as a means to 
override the requirement for unique volume labels, and rather than 
trying to fingerprint storage devices using potentially- or 
probably-duplicated storage device characteristics.  And without 
requiring local- or FC-connected SAS or SATA storage devices with 
unique serial numbers or "hidden" storage on the device.

I haven't looked recently to see if most SAS and SATA devices are now 
arriving with unique serial numbers and/or with host-accessible 
embedded storage.  If either of those is now or will commonly be the 
case, then some designs and assumptions might well eventually be 
changed within OpenVMS.

Pragmatically, it wouldn't surprise me to see an editor and 
configuration tools and updates for the existing device-configuration 
database (SYS$DEVICES.DAT, SYS$CONFIG.DAT, SYS$USER_CONFIG.DAT, 
SYS$OBECTS.DAT, et al) present within OpenVMS.  If this stuff were 
implemented now, it'd be widely different. Preferably all in SQLite or 
some other database, too. But I digress.  This current or some 
hypothetical new configuration database all eventually ties into a 
logical volume manager and related services, too.  Be nice to see tools 
and APIs to manage these and incrementally many of the other 
configuration tribbles found on OpenVMS, too.  But then I've grumbled 
about the lack of configuration-file services for all these app- and 
system-tribbles a while now.)



-- 
Pure Personal Opinion | HoffmanLabs LLC