[Info-vax] Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT)

[Stephen Hoffman]

On 2016-06-19 02:35:16 +0000, David Froble said:

> I would suggest "what does it matter?"
> 
> It's not like some other file is going to use the unused portion of 
> some disk block, or, as suggested, unused part of 4096 bytes ....

If I'm mapping the user data into memory, having its size is useful.  
Otherwise, I slog through RMS records or such.

If I'm messing with disk allocations and more directly managing storage 
— something I'd prefer to avoid, but that can arise on OpenVMS and 
other systems — then the total size of the file including all user data 
and all of its overhead and/or pre-allocation and/or metadata is of 
interest.

This is akin to UTF-8, where you might be looking for the numbers of 
glyphs in the string, or for the size of the required memory buffer to 
store the string.

Many OpenVMS apps simply don't have the concept of mapping the entire 
file into memory, they assume datasets far larger than available memory 
and/or comparatively weak and slow paging I/O support, and for those 
apps the total data size wasn't really a factor.   They're written to 
deal with records.   (This is also where the overhead of dealing with 
zillions of small hunks via RMS — and not a few and larger hunks — can 
become a run-time performance-limiting factor.)  For apps that map 
whole files or that map masses of data into memory, the user dataset 
size (modulo any virtual memory allocation granularity in play) tends 
to matter more, unless those apps are implementing their own paging — 
as various databases do.

Defining data structures and allowing the run-time system to pack and 
unpack records for the app is a concept that largely doesn't exist on 
OpenVMS.  You have to roll your own (glue) code to do that.


-- 
Pure Personal Opinion | HoffmanLabs LLC