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

[Paul Sture]

On 2016-06-26, David Froble <davef at tsoft-inc.com> wrote:
> Simon Clubley wrote:
>> On 2016-06-25, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>>> OpenVMS has not integrated the MOUNT command or the mount system 
>>> service with mount points or links.
>>>
>> 
>> The MOUNT command as currently implemented (and the underlying
>> monolithic mass of filesystem code in the kernel) is not exactly
>> VMS's best selling point.
>> 
>>> 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.
>> 
>> 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 ?
>> 
>>> 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).
>> 
>> 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.
>
> Why do you think that MOUNT should be able to handle some format that
> it doesn't know about?
> >
> Perhaps if you wish to implement a FAT32 filesystem driver, then you
> should also implement the method(s) for mounting the filesystem.

I think that what Hoff and Simon are complaining about is that the
programming interface to MOUNT is inflexible and undocumented.

$ HELP MOUNT /MEDIA
 
  /MEDIA_FORMAT

        /MEDIA_FORMAT=CDROM

     Mounts a volume assuming the media to be ISO 9660 (or High
     Sierra) formatted.

     The /MEDIA_FORMAT=CDROM qualifier instructs the mount subsystem
     to attempt to mount a volume assuming the media to be ISO 9660
     (or High Sierra) formatted.

That's a pretty specific case for CD-ROMs, further complicated by:

        Because it is possible to record parts of a CD-ROM in Files-
        11 ODS-2 and other parts in ISO 9660 format, this qualifier
        can be used to specify a CD-ROM mount (ISO 9660 or High
        Sierra).
   

-- 
There are two hard things in computer science, and they are cache invalidation,
naming, and off-by-one errors.