 |
The Question is:
I have a large RMS file that is Fragmented. Using a product called Perfect disk
it states the file has over 1,400 fragments. The size of the file is
23,617,385M blocks. If I dump the header information it states: the value of
154 for "Map areas in use".
I Remember reading many years ago something about the INDEXF.SYS and value of
155 giving error message about "no more files can be added to the disk."
Was this a pre V6 problem? Are the values for the map areas in use still in
range of (9 - 155)? The reason this file never gets defragmented it is opened
24*7*365
Regards
Mark
The Answer is :
Your recollection of around the INDEXF.SYS is correct. It is true that
INDEXF.SYS is limited to a single file header, which makes the map area
word limit of 155 significant. This is also true of pagefiles, swapfiles
and system dump files. It is NOT relevant to any other file types.
When the map area in the header of a "normal" file fills up, OpenVMS
allocates an extension header in which new extent pointers are stored.
You can follow the chain of extension headers using DUMP/HEADER/BLOCK=COUNT:0
Note the "Extension file identification:" field. DUMP will also display
the extension headers all along the chain. Since each header can contain
between 50 and 70 extents, your file with 1400 extents will comprise
somewhere between 20 and 30 extension headers, assuming no other attributes
that consume header space (eg: ACLs).
You can continue to add extension headers until you run out of disk space
or file headers. The file will continue to *work* correctly, but it may
suffer in performance. To find a specific block, the system may need to
walk the extension header chain sequentially.
The OpenVMS Wizard once observed an RMS indexed file in which the root
bucket, originally contained in an extent pointed to from the first header,
had been split. The overflow bucket was allocated to an extent pointed to
from an extension header some 50 or so headers down the chain. The I/O
performance for this file was unsurprisingly rather dismal.
If this file is regularly accessed in an environment where performance is
critical, the OpenVMS Wizard would recommend this file be CONVERTed on a disk
with excess contiguous free space, and with generous RMS ALLOCATION and
EXTENSION values for all file areas. This will help keep the file, if not
contiguous, at least in a single file header. If this file is not
performance-sensitive -- it is a log file, for example -- it is harmless.
The OpenVMS Wizard would also use DFU (Freeware) or a similar tool to
evaluate the fragmentation level of of the volume, and would use BACKUP
or other tool to defragment it as needed. Further, an investigation of
the settings of the initial file allocation and file extension sizes
are definitely warranted. These settings are available on a process,
file, volume, and system-wide basis.
|
|
|
|
|
