[Info-vax] New filesystem mentioned

[Dave Froble]

On 5/14/2019 12:53 PM, Bob Gezelter wrote:
> On Tuesday, May 14, 2019 at 12:32:35 PM UTC-4, Dave Froble wrote:
>> On 5/14/2019 11:19 AM, Stephen Hoffman wrote:
>>> On 2019-05-14 12:21:12 +0000, Simon Clubley said:
>>>
> ...
>> 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.
>>
>>>   Maybe BACKUP would then get fixed here too, assuming
>>> BACKUP would not be replaced by an improved and faster design?  For
>>> related details here, see the user- and API-visible portions of the
>>> OpenVMS work underlying the undefined file attributes support added for
>>> the ODS-3 and ODS-4 ISO-9660:1988 file system support.
>>>
>>> Making metadata dependencies optional in the higher-level software and
>>> in the apps would be very useful, particularly when adopting a plug-in
>>> scheme for file system support.  This for kernel support, as well as
>>> support for a FUSE-like file system in user space.  Basically, this
>>> means that some volumes might be "RMS immune" or "RMS incompatible", in
>>> practical terms.  You get a stream of bytes or a stream of sectors and
>>> both being sequential organizations, or you can get to use your own
>>> record structures on this file system, or you can use an integrated or
>>> add-on database package for your storage.
>>>
>>> A host reading and writing the file system and its metadata must also
>>> cause other hosts sharing that storage to manage the local and
>>> now-incoherent cache contents appropriately; cache reloading, cache
>>> eviction and/or wholesale cache flushing; there must be cache
>>> coordination.  While SSD storage is much faster than Hard Disk Drive
>>> (HDD) storage, main memory is yet faster still, which means there'll
>>> still be interest in I/O caching in main memory.  (A design difference
>>> in the existing OpenVMS caching underlies the Shared Stream I/O (SSIO)
>>> corruptions, too.
>>> http://de.openvms.org/TUD2012/opensource_and_unix_portability.pdf )
>>
>
> With all due respect, RMS data is NOT included in directory entries (reference: the ODS-2 specification OR McCoy sanitized version published by Digital Press). If RMS metadata were stored in the directory, VERIFY/LOST would clearly not be functional.
>
> RMS metadata is split between the file header (for sequential file information), and a combination of the file header and "within the file" data for direct and indexed files.
>
> - Bob Gezelter, http://www.rlgsc.com
>

Entirely correct.  It's been some time since I worked on this stuff.  I 
confused file header with directory entry.

But what you're saying confirms what I tried to say, the RMS metadata is 
not in the filesystem.  It's in the RMS data.

I guess that brings into the discussion of what "owns" the file header? 
  Perhaps I'm not correct?

-- 
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