[Info-vax] New filesystem mentioned

[Dave Froble]

On 5/14/2019 1:56 PM, Simon Clubley wrote:
> On 2019-05-14, Dave Froble <davef at tsoft-inc.com> wrote:
>> On 5/14/2019 11:19 AM, Stephen Hoffman wrote:
>>> The Record Management System (RMS) metadata details have to be stored
>>> somewhere.  Or reconstituted somehow.  Metadata such as that associated
>>> with sequential, relative and indexed files will have to be persisted in
>>> some file system data structure.
>>
>> It's always been my impression that the RMS metadata is stored in the
>> data records and directory entries.  Such as the two bytes (I seem to
>> recall) at the front of each relative file record.  Not any part of the
>> filesystem.
>>
>
> Where RMS metadata is stored is filesystem specific.
>
> For example, with NFS, you can set things up so that the metadata
> is stored in another small file alongside the real file.
>
>>>   This gets interesting when adopting
>>> some file systems such as the Microsoft FAT or ExFAT file systems,
>>> ISO-9660:2013, ISO-9660:2017, UDF, or other more portable or more
>>> transportable file systems.  The other systems would have to ignore or
>>> to support the RMS metadata, or RMS and RMS-using apps would have to be
>>> modified to remove or rework the related system and app-related metadata
>>> requirements.
>>
>> I really don't understand this concern.  If directory entries contain
>> some RMS metadata, and I think they do, that can just be ignored by
>> things that do not need the data.
>>
>
> As Bob has already mentioned, the RMS attribute data is stored in
> the file header for the ODS-2/ODS-5 VMS filesystems.
>
> In a newly designed modular system, you should be able to store the
> RMS data somewhere (ie: NFS) or fake it (ie: mount/undefined_fat).
>
> Linux actually has a similar problem at the moment. FAT32 does not
> support owner and group permissions so defaults are applied when
> you mount a FAT32 filesystem under Linux. If you don't like the
> defaults, you can change them using the mount command.
>
> For me, this works just fine when I need to access a FAT32 filesystem
> on Linux.
>
> Simon.
>

As an example I'll explain what is done in the DAS database.

Each "file" has two or three segments.

1) The first 8 blocks contain record definitions and other file specific 
information, such as current number of records, maximum allowed number 
of records, and a whole bunch of other information.  We call this the 
"file definition".  In some databases this might be call the table 
definition.  But it's not quite the same thing.

2) If a keyed file, the key records, as binary trees.

3) Actual data records.

The idea is, all the database needs from storage is a place to store the 
file's contents.  The database code then knows how to handle file 
requests.  Actual access to the data is via transfers of 1-127 512 byte 
disk block into an I/O buffer.

There is no need for the VMS filesystem to know about the database 
files, nor for the database to know about the filesystem, other than how 
to access the file(s).  (QIO)

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486