[Info-vax] MOUNT and filesystems, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was

[Stephen Hoffman]

On 2016-06-25 19:44:38 +0000, Simon Clubley said:

> On 2016-06-25, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> 
>> OpenVMS lacks a volume manager.
>> 
>> OpenVMS support for storage device management and storage device 
>> swapping is limited at best.
> 
> OTOH, you can do things with volumes in VMS clusters, especially when 
> things go wrong, that you can't do elsewhere.

One of the few (only?) distinctive features of OpenVMS and clustering 
remaining is multi-host RAID-1, and the DVE/DDS support.

Most of the other capabilities of clustering that an application might 
seek to use can be implemented — variously through entirely different 
means, but with similar results — on other platforms.

> The terms "volume manager" and "storage device management" cover a wide 
> range of areas. So that I understand you, what _exactly_ are you 
> looking for (with examples if possible) with the last two items ?

I was answering a question.

OpenVMS volume management is crayon-grade.  It certainly works, but 
it's manual.

What would I prefer to see?  I'd prefer to see volumes become far less 
interesting to applications with the integration of the mount point 
support, the ability to automatically mount or re-mount volumes in 
cluster and NFS configurations (and the integrated SMB and WebDAV 
clients, if those ever arrive) as the hosts come and go (what some of 
us use MSCPMOUNT for), and I'd prefer the ability to notify on storage- 
and volume-level errors (error handling and notifications are another 
area of OpenVMS that was quite good to start, but that has subsequently 
degraded into a free-for-all of a zillion different tool- and 
app-specific solutions), the ability to automatically detect WWIDs and 
to manage the FC scanning without all the manual schtick currently 
required — not modifying or mounting detected volumes, but avoiding the 
WWIDMGR dance and the absurdly manual FC SAN configuration and 
management where that can be automated and integrated and preferably 
avoiding the need for the  rd_devid (xec) and management_in (xa3) 
commands if possible,  better automation of the DVE/DDS volume growth 
operation, rid of the manual editing of the sys$config and 
sys$user_config,and it'd be nice to have USB sector-addressable storage 
volumes automatically detected and made available.   Volume-level 
encryption and the related key management, too.   Background scrubbing, 
for those that cling to rotating rust.   Managing snapshots and local 
and off-site backups.   Storage allocation and storage migration 
support too, and preferably transparent — but some apps are going to 
squabble or are going to need to change.   Among other details.

Just having a MOUNT-integrated database with a list of which volumes 
are in use or are scratch, and which projects and users are on what 
volume, and the interface to the central password and certificate 
store, would be nice, too.

Take a long hard look at the storage-related DCL glue code in 
SYSTARTUP_VMS and SYCONFIG and SYSHUTDWN and SYSHUTDWN_0010 and 
MSCPMOUNT and elsewhere, and start to work to remove it.   In short, 
take what your average system manager has to do to manage your average 
moderate-to-large non-static storage configuration and across the 
current suite of disparate tools involved (BACKUP or other backup tool, 
SHOW ERROR and ELV, MOUNT, etc), and better automate it.

Yes, some of you are working at sites with servers and volumes and 
configurations that seldom change or that never change.  With 
SYSTARTUP_VMS and SYSHUTDWN and such having reached a state of utter 
perfection.   Good on you.  Good job.  Seriously.   Volume management 
features and better storage automation are probably not for you.  But 
even among some of these sites, I suspect there are features here that 
you could use, though.

Are all of these necessary?  Of course not.  But consider what features 
will OpenVMS be competing with and competing against, and what those 
other platforms will be providing, in five or ten years, too.

>> The configuration and related commands are manual, file-based and the 
>> associated commands and syntax and configuration required (for 
>> configuring USB devices, for instance) tends toward arcane and manual.
>> 
>> Then there's that MOUNT — which is useful for other purposes in the I/O 
>>  system — is currently tied to disk and tape storage, and to specific  
>> disk formats.   That design and that limit is not a surprise, but more  
>> than a little of the underlying flexibility around ACP handling (yes,  
>> ACPs are undocumented) was lost to developers here.  But I digress.
> 
> IMHO, I agree with you on this one. Based on what general knowledge I 
> know of how it's implemented internally (I've never seen the VMS source 
> code), MOUNT internals are a disaster area if you ever wanted
> to implement general mount support in VMS for a variety of filesystems 
> in the way that it's possible in Linux (for example).

The MOUNT code is good code, but the design is old and limited.   MOUNT 
has carnal knowledge of the supported file systems.  There's no support 
for user-mode nor inner-mode file systems; for FUSE or for the ability 
to add and integrate additional file systems.   There's no way to get 
MOUNT to launch an ACP on a non-storage or 
storage-but-non-recognized-format device, for that matter.   There are 
examples such as NFS, which didn't have a way to use MOUNT, and various 
products which use ACPs to "assist" with driver-specific processing.

> You should be able to write (for example) a FAT32 filesystem driver 
> from public documentation and use a MOUNT command to mount it in the 
> same way as you can with an ODS-2 volume.

That's one of many examples of what's missing here.



-- 
Pure Personal Opinion | HoffmanLabs LLC