[Info-vax] File Systems

[Stephen Hoffman]

On 2015-03-05 04:54:26 +0000, David Froble said:

> clairgrant71 at gmail.com wrote:
>> 
>> This is a new file system. We started the work before VMS was sent to 
>> India. We intend to pick up where we left off.
> 
> When can we get some details on the new file system?

As a guess, that's probably at least a bootcamp or two into the future, 
in any technical detail.

> Will it replace ODS-2 and ODS-5, or will it be in addition to them?

ODS-2 might fall off the x86-64 support bus as part of the x86-64 port 
— as ODS-1 did — but this new file system will coexist with ODS-5 for 
some time.

Most production sites in general and most VMS sites are loathe to test 
a new file system anywhere near production, and will need some time and 
some incentive to migrate to this new file system.    How much stuff 
hasn't yet gotten fully migrated over to ODS-5, after all?  Several of 
the projects on the local docket are all very firmly still lodged 
within the ODS-2 limits for filename length and for the character set 
and that's not likely changing anytime soon.  Getting native UTF-8 
throughout?  That's no small project in DCL, and in the command 
utilities, much less the rest of the environment and the critical 
third-party applications.

> I have a database product that does QIOs to access (read and write) 
> from 1 to 127 blocks.  Will there be incompatibilities?  It would be 
> good to get as much of a head start if needed as I can.

The fast I/O path using $io_perform[w] has been available for a while 
now.   Might want to start looking there.  VSI will very likely not 
likely mess with folks doing block I/O via either $qio[w] or 
$io_perform[w] and with what are now comparatively dinky virtual reads 
and writes.  That'd break too much existing code within VMS and within 
layered products and within third-party applications.  For no 
(apparent) good reason.

Where there's sufficiently good reason to warrant it and where there's 
an obvious benefit to moving forward, I'd like to see some API 
breakage.  But I just don't see a benefit to lowering what is already a 
comparatively small I/O transfer limit, nor in disrupting the virtual 
I/O path.

If you're using logical I/O and not virtual I/O here, well, why would 
you care?  You basically already are the file system, after all.  Go 
all in, and use the whole disk.



-- 
Pure Personal Opinion | HoffmanLabs LLC