Relationship of File Headers to Maximum Files Allowed

[CharlieCalhoun]

What is the relationship of file headers to maximum files allowed.

I recently migrated from one disk to another. I did not do an image backup, I only moved the data I needed to. Being cognizant of the number of small files I was moving, I initialized the new disk with a small cluster size. What I see is that I have a very unfragmented volume. The maximum number of files is greatly larger than the number of free headers and I don't understand why. I know I can use the /MAXIMUM_FILES parameter when initializing the volume but that doesn't appear to help me increase the number of file headers. What am I missing?

I used the following command to initialize the disk.

INIT/NOHIGH/STRUCT=5/LIMIT $1$DGA91: ECP_DISK3

***** Volume info for ODS5 volume $1$DGA91: (from HOME block) *****
Volume name : ECP_DISK3
Volume owner :
Volume set name :
Highwater mark. / Erase on del. : No / No
Cluster size : 3
Maximum # files : 16711679
Header count : 1118010
First header VBN : 4093
Free headers : 11221

***** File Statistics (from INDEXF.SYS) *****
INDEXF.SYS fragments/ map_in_use : 4 /11 words ( 7% used)
Total files (ODS2 / ODS5) : 10 / 1106639
Empty files : 11195
Files with allocation : 1095454
Files with extension headers : 37
Files marked for delete : 0
Directory files : 185102
Contiguous files : 1085424
Total used/ allocated size : 113084349 /115295802 blocks
Total headers/ fragments : 1106696 /1129806
Average fragments per file : 1.031
File fragmentation index : 0.145 (excellent)
Average size per fragment : 102 blocks
Most fragmented file :
$1$DGA91:[ECP.LIVE.277]HP_9E049_NONSTDU.RSP;136 ( 25969/25971 blocks; 278 fr
agments)

***** Free space statistics (from BITMAP.SYS) *****
Total blocks on disk : 419430400
Total free blocks : 304134600
Percentage free (rounded) : 72
Total free extents : 217
Largest free extent (blocks) : 207548418 at LBN: 211881981
Average extent size (blocks) : 1401541
Free space fragmentation index : 0.000 (excellent)

[Jess Goodman]

The /MAXIMUM file qualifier sets the size of the index file bitmap. This is an area that comes before the first file header in INDEXF.SYS and each bit represents whether a file header is is use or not. This area can not be expanded.

The /HEADERS qualifier specifies how many flie headers are initially allocated in INDEXF.SYS. If /HEADERS is less than /MAXIMUM, as it usually is, then more file headers will be allocated later if required by file growth, assuming INDEXF.SYS can be extended.

(INDEXF.SYS can only have only one file header itself so there is a limit to how many times it can be extended. Using a large initial /HEADER count reduces the chance of this.)

[John Gillings]

Charlie,

The header count is the number of headers currently existing. Maximum files allowed is the maximum it can ever grow to.

Look up in the internals how INDEXF.SYS works. In a nutshell, it contains a header bit map, (sized by /MAXIMUM_FILES), an extent bitmap (worked out from the size of the disk and the cluster size), and the headers themselves.

The header bitmap is fixed forever when the disk is initialized. The extent bitmap was fixed, but it can now (>= V7.3-2) be expanded with the dynamic volume enhancement. The number of headers initially allocated is controlled by /HEADERS. It can expand as required. In V5.5 days this was a problem because the initial allocation was pitiful (16!) and the expansion algorithm was poor, often leading to the header of INDEXF.SYS filling up. These days expansion is handled quite well so you have to try very hard to find a pathological allocation pattern to induce a HEADERFULL condition on the disk.

If you really want to preallocate more headers, use INIT/HEADERS (see help for details). Most of the time you can trust the defaults.

[Robert Gezelter]

Charlie,

First, allow me to extend a welcome to the ITRC OpenVMS Forum!

It would appear that the volume was initialized allowing a maximum of 16,711,679 files, with the index file containing 1,118,010 headers, of which 11,221 are presently not in use.

As has been noted, the MAXIMUM_FILES parameter governs the size of the bitmap, the headers are actual blocks in the index file.

The bitmaps used for volume management are fixed at initialization (as opposed to the overall size of the index file, which can grow within the limits of its single file header). The dynamic volume expansion support (in 7.3-2 et seq.) uses a pre-allocated large bitmap, in concert with the "fence" at the end of the volume, to allow the volume to be "extended" on the fly.

The dynamic extension capability, when used with host based volume shadowing, as some interesting implications, as I pointed out in " Migrating OpenVMS Storage Environments without Interruption or Disruption" at the 2007 HP Technology Symposium in Las Vegas (slides available at: http://www.rlgsc.com/hptechnologyforum/2007/1512.html ).

- Bob Gezelter, http://www.rlgsc.com

[CharlieCalhoun]

Thanks for the information guys. I'll pull some of your information together here for one final question.


If /HEADERS is less than /MAXIMUM, as it usually is, then more file headers will be allocated later if required by file growth, assuming INDEXF.SYS can be extended.

The header bitmap is fixed forever when the disk is initialized. The extent bitmap was fixed, but it can now (>= V7.3-2) be expanded with the dynamic volume enhancement.

The dynamic volume expansion support (in 7.3-2 et seq.) uses a pre-allocated large bitmap, in concert with the "fence" at the end of the volume, to allow the volume to be "extended" on the fly.

These days expansion is handled quite well so you have to try very hard to find a pathological allocation pattern to induce a HEADERFULL condition on the disk.


OK, so it should expand on it's own now (I'm running 8.3) and create more available headers as needed?

BTW, I'm watching this closely because I have, on two occassions, run into a HEADERFULL condition on the disk I migrated this data from and I don't want to run into that again.

Which leads me to my final question. With my bad experience with the prior disk headerfull issue, I'm not confident that the volume will expand as necessary. That coupled with the fact that the prior volume had the same max_files yet 4 times the number of headers, do you agree that I should reinit this disk with the headers parameter rather than counting on dynamic expansion? BTW, I was down to less than 300 free headers yesterday before I deleted files to get it up to 11k free. How close to zero should it get before expanding?

[Robert Gezelter]

Charlie,

The volume will not extend on its own. The command to reset the limit to reflect a larger device size must be done. Of course, this is done after the SAN container, or underlying physical volumes are expanded (and the data is moved to them using the appropriate shadowing/mirroring mechanisms).

The change at 7.3-2 was allowing the end of volume number to be changed without dismounting the volume. Thus, as my presentation demonstrated, it is possible to migrate and expand storage volumes while users continue to use the volume without interruption.

- Bob Gezelter, http://www.rlgsc.com

[Volker Halle · Accepted solution]

Charlie,

you get HEADERFULL, if the INDEXF.SYS file header has used all of it's space for retrieval pointers in it's file header and the INDEXF.SYS file cannot be extended anymore, thus you can't create any more files on that volume.

In your DFU output, you'll see that as:

INDEXF.SYS fragments/ map_in_use : 4 /11 words ( 7% used)

If this goes to 100%, you can expect to see HEADERFULL soon.

The INDEXF.SYS expansion will only happen, if there are 0 headers free and another free header is needed.

If you have an idea on about how many files will end up on that volume INIT/HEADER=x (with x at least the no. of files you expect) is a very good idea. This will prevent the need of frequent extensions of INDEXF.SYS and reduce the risk of HEADERFULL.

This has nothing to do with DVE (Dynamic Volume Expansion). That feature allows you to increase the no. of disk blocks useable on the disk while the disk is mounted. It won't help with HEADERFULL problems.

Volker.

[Andy Bustamante]

You may also want to consider modifying the /cluster_size. This is one thread http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1216312968426+28353475&threadId=1150519 with discussion of points to consider.

The /directories switch allows you to reserve a larger master file directory (000000.dir) from the start, if you many files are arranged in many directories.

Andy Bustamante

[John Gillings]

Charlie,

Some history of HEADERFULL...

Today I can walk into any newsagent or supermarket and buy a 1 or 2GB USB thumb drive from a "clearance sale" box for less then $10. Back in the early 1990s an RZ26 SCSI disk (1GB) cost $2000. When VMS was first designed, a 50MB disk was the size of a washing machine and cost more than $20000.

Up to VMS V5.5 the default for /HEADERS was 16 and the algorithm for expanding INDEXF.SYS was very simple "1000 blocks". This was appropriate when each byte of disk space had a significant cost.

Since a file header has up to about 70 extent slots, that meant, by default, INDEXF.SYS would reach a maximum size of about 70000 blocks, giving enough headers for maybe 60000 files (depending on disk and cluster size). This was fine for sub 1GB disks, but as disk sizes grew it became a serious limit.

Although it was possible to initialise disks with higher initial allocations of headers, the expansion algorithm was inadequate, and reinitialising a disk and rebuilding it was non-trivial and required downtime (backup and restore took a long time, and since disks were expensive, to would usually be out to tape and back again to the same disk, so therefore a risk).

As of VMS V6, the expansion algorithm was changed to consider the amount of free space, the number of files already on the disk and their average size. This meant that the system has 50 or 60 attempts to predict the final requirements for the disk. Most times it would expand to the correct size in 2 or 3 steps. If you have a very odd usage pattern you might confuse it, or fragment the disk too quickly, but most disks that ever reach HEADERFULL were initialised pre V6.0.

That said, if you have a good estimate for the number of files you will store on a disk, it's in your interest to give that information to the operating system when you initialise the disk, rather than expect it to be discovered.

[Debasis Bhar]

Just curious. If i know that i will be having nearly XXXXX files in my disk shall i use /header=XXXXX or /Maximum_files=XXXXX ?

Regards,
Deb