Since the header of INDEXF.SYS is itself contained inside INDEXF.SYS,
there would be some nasty recursion issues involved. Consider,
INDEXF.SYS need only be extended if *ALL* headers are currently in use.
Therefore, where are we going to allocate the extension header from? The
extent which contains the extension header would have to be pointed to by
the extension header itself so how would you find that extension header the
first time? Catch 22. Clearly there are ways around all this, but
they would represent (messy) special cases in the file system and
organisation of INDEXF.SYS. When you also consider that an extension
header on INDEXF.SYS might (will?) result in reduced performance (like a
potential extra disk I/O every time a new file is accessed) it's simply
not worth the mega headache implementing an extending INDEXF.SYS.
If you have a disk in the HEADERFULL state, the short term workaround
is to delete files. For each file you delete, you will free at least
one header. Long term, you need to perform an image backup and restore.
My recommendation is to simply:
$ BACKUP/IMAGE/VERIFY disk backup-media
$ BACKUP/IMAGE/VERIFY backup-media disk
There is usually no need to reinitialise the disk in between because
BACKUP will make a contiguous INDEXF.SYS the same size as the current
one. In most cases this will only need to be done ONCE for the lifetime
of a disk. I've seen a few cases where one repeat was necessary (at > 6
month interval) and a single, pathological case which needed 3.
If you use the very latest version of Polycenter File Optimizer (V2.1)
you will be able to use the new "offline" feature to defragment
INDEXF.SYS as long as the disk is dismounted first.
How to prevent it? When INITIALIZing a disk for the first time you
should try and make sure you specify a reasonable value for /HEADERS.
Use a *conservative* estimate of the actual number of files which will
be stored on the disk. Part of the problem is the default (16) is
*very* low for most uses of a disk. (At this point is should be noted
that it is always possible to expand INDEXF.SYS by performing an image
backup of the disk, but there are certain circumstances where it is
not practical to compress INDEXF.SYS, so if it is over allocated, the
excess blocks are effectively lost. It would therefore be unreasonable
to increase the default allocation as there are some users who wish
to place a small number of large files on a disk. Arbitrarily
increasing the default number of headers could be stealing blocks from
such users in circumstances where they could not be recovered). So,
choose a slight underestimate of the number of files you expect on
the disk. There is room for around 60 extensions of INDEXF.SYS so
don't worry too much about expansion, but remember that *contraction*
may be impossible.
If you forgot to specify the number of headers, you can monitor the
growth of INDEXF.SYS using the DUMP/HEADER command. See the value of
"Map area words in use" for example:
$ dump/head/block=count:0 sys$sysdevice:[000000]indexf.sys
Dump of file SYS$SYSDEVICE:[000000]INDEXF.SYS;1 on 7-FEB-1996 08:31:42.66
File ID (1,1,0) End of file block 6057 / Allocated 6057
Header area
Identification area offset: 40
Map area offset: 100
...
VAX-11 RMS attributes
Record type: Fixed
...
Directory version limit: 0
File characteristics: Contiguous best try
Map area words in use: 48
...
The maximum value is 155, the minimum is 9. The above example shows a
mildly fragmented INDEXF.SYS. If you see a disk which is above (say)
145 you may wish to consider a "preemptive" image backup and restore
(or PFO OFFLINE defrag) so you don't hit HEADERFULL. For a system
disk on OpenVMS/Alpha, you could (at least in theory) use PFO from
standalone (I've never tried it though).
Note that once you have expanded INDEXF.SYS to a size which, for your
disk usage pattern, allows you to fill the disk, you will NEVER have to
worry about HEADERFULL again (unless you reINITIALIZE the disk). Once
the usage has stabilized, it really doesn't matter how many extents
there are.
It is also worth noting that HEADERFULL is largely an artifact of
OpenVMS V5.5-2 and below since OpenVMS V6 and above have a new
algorithm for expanding INDEXF.SYS which takes into account the
apparent disk usage and current freespace before deciding how many headers
to extend by. The V5.5-2 algorithm was reasonable for the times it was
design for (pretty much when a 50MB disk was the size of a washing machine
and noone had every heard of gigabytes :). It even performs quite
reasonably on large disks for some common usage patterns. In any case,
under OpenVMS V6 and above, you can *almost* forget about this problem
(there will always be pathological cases which defeat the logic of the
expansion algorithm).
