|
HP OpenVMS Systemsask the wizard |
|
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.
|