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

[David Froble]

Stephen Hoffman wrote:
> 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.
> 
> 
> 

I'd think that the whole system of device handling in VMS could use a serious 
look, and re-design, to incorporate things that have appeared since the original 
work was done.  MOUNT is just a part of this.

Now, I know you probably know this, MOUNT /FOREIGN gives an application access 
to a device.  No, it's not the OS that does anything.  And yes, you'd want the 
OS to handle the device, not an application.  Probably should not have mentioned 
this ....

:-)