[Info-vax] Large mailboxes - RMS Indexed file internal design

[Stephen Hoffman]

On 2020-12-06 17:14:13 +0000, Michael Moroney said:

> Stephen Hoffman <seaohveh at hoffmanlabs.invalid> writes:
> 
>> This also given we're (hopefully) migrating from the longword logical 
>> block addresses (2 TiB limit) to longer will be disruptive, and given 
>> we're using other databases for many apps.
>> Maybe once we're past 2 TiB and headed for exabyte-scale volumes, RMS 
>> indexed updates will be interesting.
> 
> You'll be happy to know that VMS addressing drives larger than 2TB has 
> already been done (largely by myself) and will be in V9.x, and is in a 
> V8.x version  which may or may not see the light of day.  This will not 
> help with Files-11 since ODS-2/5 also has a 2TB limit and really can't 
> be updated. To use the changes will require a new file system.

Trivia: OpenVMS has supported sector addressing past 2 TB starting with 
V8.4; for over a decade. You've added sector addressing support for 
storage capacities past 2 TiB.

Addressing support past 2 TiB likely isn't widely useful for those of 
us with RMS dependencies, though. SQLite, Rdb, and such can likely be 
modified, depending on what interfaces the XQP presents.

Might want to chat with the VSI developer-relations folks, around what 
changes our apps are headed for with (presumably) 64-bit LBNs, so that 
we might ponder what changes will be necessary. This as part of the 
upcoming second beta for OpenVMS x86-64, presumably.  e.g. $io_perform 
XQP access only? Maybe with some example code?

And FWIW, a supremely ugly hack-around for the ongoing 2 TiB RMS limits 
would involve a GPT-aware partitioned device driver, possibly mixed 
with my ever-favorite bound-volume support. 🤮 As has undoubtedly been 
suggested before.



-- 
Pure Personal Opinion | HoffmanLabs LLC