[Info-vax] New filesystem mentioned

[Arne Vajhøj]

On 5/13/2019 9:56 PM, Dave Froble wrote:
> On 5/13/2019 8:52 PM, Arne Vajhøj wrote:
>> On 5/13/2019 8:30 PM, Dave Froble wrote:
>>> On 5/13/2019 6:53 PM, Arne Vajhøj wrote:
>>>> On 5/13/2019 5:37 PM, Dave Froble wrote:
>>>>> On 5/13/2019 2:36 PM, Michael Moroney wrote:
>>>>>> Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>>>> There's a reason (multiple reasons actually) why so many operating
>>>>>>> systems now support ZFS.
>>>>>>
>>>>>>> Unfortunately, VMS isn't likely to be one of them, given the lack
>>>>>>> of support in VMS for modular plugin filesystems. That means adding
>>>>>>> ZFS to VMS would be a major job.
>>>>>>
>>>>>> If I recall, A mentioned that ZFS and other file systems lacked the
>>>>>> cluster support
>>>>>> needed for clusterwide operation that VMS needs, and would require
>>>>>> mega rototilling
>>>>>> to add it. I don't know the details.
>>>>>>
>>>>>
>>>>> An interesting statement.
>>>>>
>>>>> I'm wondering what would be required in the filesystem to support VMS
>>>>> clustering?
>>>>>
>>>>> Not that I'm an expert on VMS clusters, but it has been my impression
>>>>> that the OS did all the work.  But what do I know?
>>>>
>>>> The answer must depend a lot on what is meant by "file system".
>>>>
>>>> I do not think there is anything in the on disk bytes that
>>>> are relevant for clustering.
>>>>
>>>> The code that does the physical transfer of data between
>>>> disk and memory should not have anything relevant for
>>>> clustering.
>>>>
>>>> But there are some higher level code that need cluster
>>>> awareness. At least code that checks if a file being
>>>> opened is already in use on another node. And much more
>>>> to support effective locking of records and byte ranges
>>>> in cluster environment.
>>>
>>> The DLM is cluster aware, and any locks are respected over the entire
>>> cluster.
>>>
>>> For file system locks, the top level locks might be on the filespec,
>>> which includes device.  As I may have mentioned, I'm not very
>>> knowledgeable about VMS clusters.  Someone who knows more can add some
>>> details.  I believe every "disk" in a cluster has a unique name.  So
>>> the resource lock on that device and filespec should be respected and
>>> unique throughout the entire cluster.
>>>
>>> The sublocks are for record numbers in the file, and would be
>>> respected throughout the cluster.
>>>
>>> I believe it's just that simple.
>>>
>>> Now, the "stuff" that makes the DLM work across the VMS cluster, that
>>> may be rather complex, but, it's already in there.  There are things
>>> such as moving the locks to the node with the most usage, and such.
>>> Really a nice tool, and from the early 1980s.  I used it for my
>>> database product developed in 1984.  Still working.
>>
>> Yes.
>>
>> But now you are assuming that ZFS is just an ODS-something format and
>> that RMS, SYS$QIO(W) etc. just runs on top of it.
> 
> So far, I don't see any problems with such assumptions.

If you read the links about ZFS that I posted then it seems that
ZFS is a lot more.

> RMS is just data, whether it's internal data, or user data.  It gets 
> stored on "disk blocks".
> 
> I'd assume (bad habit) that if any file system was implemented on VMS, 
> that QIOs would be the method for access.  Now, QIO may need to know 
> some new things.
> 
> For any file system to be implemented on VMS, it's going to have to work 
> as other file systems, else what's the use?  If low level code and all 
> new file accessing is required, the usefulness becomes much less.  Might 
> as well go back to physical I/O.  The purpose of a file system is to be 
> a lower level tool transparent to user code.

To user code: yes.

But there is a lot between the SYS$QIO(W) and RMS API's and the plates.

Arne