• Please review our updated Terms and Rules here

determining proper MAX/HEA values for BRU under RSX11

hush

hush

Experienced Member
Joined
Feb 7, 2022
Messages
319
Location
MD, USA
hey all! page 41 of the RSX11M+ v4.3 installation manual lists proper MAX and HEA values for BRU/INI for a number of drives, but some are missing and there is no way to determine proper values for arbitrarily sized disks. does anyone know the math that is being done to determine these values? it seems a bit strange, for instance, that the RA82 (a 622MB drive) and the RA90 (a 1.2GB drive) differ only slightly in the maximum number of file headers they can accommodate.

appreciate any insight!
 
I think that it is more appropriate to consider these values recommended (moreover, rather for the subsequent SYSGEN), and not proper.

In addition, the number of (allocated) headers plus five cannot be greater than the maximum number of headers.

And from personal experience - I set such values for the allocated headers and the maximum number of headers that I considered suitable - depending on what will be stored on disk.
 
Hunta said:
I think that it is more appropriate to consider these values recommended (moreover, rather for the subsequent SYSGEN), and not proper.

In addition, the number of (allocated) headers plus five cannot be greater than the maximum number of headers.

And from personal experience - I set such values for the allocated headers and the maximum number of headers that I considered suitable - depending on what will be stored on disk.
Click to expand...
are there any general rules you follow when determining these values? it all just seems a bit arbitrary to me and i'm not familiar enough with the inner workings of the I/O system to know what's best, so i'd appreciate any docs or notes you could toss my way.
 
When using the ODS-1 file system (RSX-11S, RSX-11M, RSX-11M-PLUS), (almost) all information about files is contained in the service file INDEXF.SYS, which contains (in addition to service information) file headers. The file header contains the name and extension of the file, information about the owner and protection of the file, as well as which blocks of the volume are occupied by this file.

MAXIMUM is the maximum number of file headers that can be created on a volume after it has been initialized. In fact, this is the maximum size (plus a certain constant) of INDEXF.SYS, in which these headers are located. Important facts to keep in mind:
- 5 headers belong to service files (including INDEXF.SYS itself)
- usually a file header is a single block in INDEXF.SYS, but - if the file is large enough or heavily fragmented - more blocks may be needed - or in filesystem terms - extension headers. Therefore, in reality (if there are many extension headers), fewer files can fit on the volume than the value specified in MAXIMUM
- as far as I remember, the theoretical limit for the number of headers (including service headers and extensions headers) is 65535 (or so)

When initializing a volume, a program that performs initialization (for example, INI or BRU) can immediately occupy a certain number of volume blocks for headers - this is the HEADERS parameter. If all such preallocated headers are already occupied by files - when creating a new file the file processor needs to expand INDEXF.SYS, but not more than the size specified in MAXIMUM.

And then the trade off begins - the goal is to allocate enough blocks for INDEXF.SYS so that it does not need to be expanded for some time - this is a costly operation and leads to fragmentation of INDEXF.SYS plus the speed of working with INDEXF.SYS decreases. But at the same time leave more space for regular files.

In principle, after initializing the volume, you can increase the maximum number of files, but, if memory serves me, you can’t add extension headers for INDEXF.SYS, so it’s not at all a fact that without a full reinitialization it will be possible to get the theoretical limit on the number of files.
 
Hunta said:
….

And then the trade off begins - the goal is to allocate enough blocks for INDEXF.SYS so that it does not need to be expanded for some time - this is a costly operation and leads to fragmentation of INDEXF.SYS plus the speed of working with INDEXF.SYS decreases. But at the same time leave more space for regular files.

In principle, after initializing the volume, you can increase the maximum number of files, but, if memory serves me, you can’t add extension headers for INDEXF.SYS, so it’s not at all a fact that without a full reinitialization it will be possible to get the theoretical limit on the number of files.
Click to expand...

I remember a few pathologic cases where we could not extend INDEXF.SYS in OD2(?) Volumes. I think we ran out of space for a large contiguous expansion of INDEXF.SYS, so it added a bunch of very small ones. This exhausted the the limit on extensions and limited the number of headers to well below the maximum.

There are some recommendations for ODS-1 for different size volumes at https://vt100.net/dec/aa-2573p-tc.pdf Section 4.6.6.

Jerry
 
You must log in or register to reply here.
Back
Top