HP OpenVMS Systems

Ask the Wizard

HP OpenVMS Systems

OpenVMS information

» What's new on our site
» Upcoming events
» Configuration and buying assistance
» Send us your comments

HP OpenVMS systems

» OpenVMS software
» Supported Servers
» OpenVMS virtualization
» OpenVMS solutions and partners
» OpenVMS success stories
» OpenVMS service and support
» OpenVMS resources and information
» OpenVMS documentation
» Education and training

Quick Links

» Non-javascript page
» Ask the Wizard

Test Drive OpenVMS

» OpenVMS I64 test drive
» Java test drive

Other information resources available to you include:

» OpenVMS freeware
» ECO kits, software and hardware support, prior version support
» Alpha SRM, ARC, and AlphaBIOS firmware updates
» ENCOMPASS - HP user group
» OpenVMS software downloads, OpenVMS freeware CD-ROM
» OpenVMS firmware locations
» DECconnect passive adaptor charts
» Cables reference guide
» MicroVAX console commands
» OpenVMS student research

Select a topic below to see Questions Frequently Asked by partners

» Using the online documentation library(installing BNU from the asap SDK)
» Global sections(how to create and use.)
» xx$CREATE_BUFOBJ system service(usage)
» Ethernet address(methods of determination)
» Shareable images(cookbook approach to creating one)
» Sharing data/code at absolute addresses(a guide with examples)
» Determining the Alpha microprocessor
» Using GETSYI to get hardware status

Evolving business value

» Business Systems Evolution
» AlphaServer systems transition planning
» Alpha RetainTrust program

Related links

» HP Integrity servers
» HP Alpha systems
» HP storage
» HP software
» HP products and services
» HP solutions
» HP support
disaster proof
HP Integrity server animation
HP Integrity server animation
Content starts here

Ask the Wizard Questions

File System: Defragmentation of INDEXF.SYS

The Question is:

When files are badly fragmented the header area is extended
to handle additional retrieval pointers.  This does not
seem to apply to the INDEXF.SYS file on each disk.  Why
not?  How can we work round this limitation?

The Answer is:

      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).