HPE Community Scheduled Maintenance Notification (June 29, 10pm CDT - June 30, 12pm CDT)

Click here to learn more

INITIALIZE /INDEX=xxxxx

SOLVED

I didn't want to hijack Peter's thread about "disk to disk to tape", but I was just curious about Hein's intent on wanting the index file at the beginning of the disk.

Assuming your not dealing with physical drive = volume ie. raidsets, logical drives carved out of an array, LD container files etc., does it really matter anymore where the index file is?

I believe having the index file at the beginning or middle or end was more an attempt to optimize/reduce disk head seek time, was it not? If there are many heads on many disks involved. is it not "moot"?

We are about to build new ES80's using storage presented from an EVA8000 ... just curious if I should take the /index switch into consideration when init'ing the new "disks".

Cheers,
Art

24 REPLIES 24

> [...] does it really matter anymore where
> the index file is?

It does if you're planning "to 'truncate' the
container file".

Initializing a disk is covered in http://64.223.189.234/node/193

I'd be looking at the cluster factor (minimum of 16, or a multiple of 16) and at allocating sufficient headers, and at enabling dynamic volume expansion.

The index file will typically want to be in the middle of the disk; at its default position. Yes, due to the perceived advantages in disk seeks for such a frequently-accessed file. Yes, caching can potentially eliminate the positioning benefits -- further, with multiple heads,

Stephen Hoffman
HoffmanLabs LLC

Steven>> It does if you're planning "to 'truncate' the container file".

:-)

Give the man 10 points!

>> I didn't want to hijack Peter's thread about "disk to disk to tape",

Excellent.
Future readers... that would be:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1136467

>> does it really matter anymore where the index file is?

Is does if you want maximum contiguous space!

>> believe having the index file at the beginning or middle or end was more an attempt to optimize/reduce disk head seek time, was it not?

Right. The assumption was that the dominant default application / usage case would be fill up disks with lots of smallish files (application development environment). Thus going from the file header to its data would on average involve a head seek over half of half the full seek distance.

The price for that is to force half disk seeks for near empty disks as they are being filled. And near half disk seeks at the disk fills up to get to the more recent files which are likely to me more popular.

The assumption was that non average applications, for example deploying file occupying 1/4 or more of the disk, would be smart enough to force their own INIT/INDEX.
And for a few years (decades) they were!

Nowadays I suspect that is a lost art, and I feel, like Art, that is matters much less, if any.

The specific case of the EVA?... well when you create a virtual unit (disk) the blocks are reserverd, but not actually allocated. The allocation happens in mega-byte sized chunks (4mb storage units?) on first touch, which would be the INIT. So when starting on completely clean eva disk group, even if /INDEX=MIDDLE is in effect, the actual LBNs on the disks will be the low blocks!.

(For repeatable benchmarks one has to write a pattern from LBN 0 to the end to force the actual allocation on EVA's!)

I tend to ignore /INDEX=xxx and if i do think about it, then i tend to select /index=begin

fwiw,
Hein.

Art,

I would take a moderate position on this entire question.

WADR to Hein, I would not often locate the INDEX file at the beginning of the disk. Given current disk capacities, I would also not tend to choose the absolute middle, for the reasons already mentioned.

The discussion about the history has already been mentioned, and I believe that it was cited correctly.

What DOES matter, is the (expected) file usage. If I am initializing a disk that is to be carved up solely into a pile of LD container files, putting the Index file at the beginning is not a real problem. If I know that the disk will already be half full when I start, the middle might be a better choice.

On an otherwise empty disk, that will gradually fill? Probably I would place it some percentage of the way in, with the expectation that I would be expanding the volume at a later date (see my presentation on expanding volumes without interrupting users at http://www.rlgsc.com//hptechnologyforum/2005/1146.html ).

Absent some hard statistics, this is an almost unresolvable question. The presence of caches at various places (device, controller, host, XQP, RMS) tends to obscure, rather than clarify the issue. Personally, I try to analyze issues without the assumption of caches: decisions that are good tend to get better with caching.

My US$ 0.02.

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

Art,
My 2c too...

Yes, the original intent for placement of the index file was seek times, and yes, it's not that relevant in the context of some current technologies - LD, partitioning, EVA, caches, etc. By default, allocations would be taken from the largest contiguous chunk, so filling a disk would tend to grow outwards, alternating sides for equal sized allocations. This was good for seeks because it tended to keep the disk well localised (though a large file with small extensions could get distributed further and further apart).

As Hein pointed out, one reason to choose "BEGINNING" or "END" would be to maximise the (possibly virtual) contiguous space on the volume.

I'd say something that's potentially more important than the location of INDEXF.SYS is to specify a reasonable estimate for its initial size using the /HEADERS qualifier. Regardless of storage technology, extent slots in the header of INDEXF.SYS are a VERY finite resource. Granted, the post V6.2 algorithm for extending INDEXF.SYS is far better than the previous one, but an underestimate on the INIT (or default /HEADERS=16) risks pushing a volume into HEADERFULL state.

Unless you have good reasons for choosing otherwise, I'd tend to go with the default "MIDDLE", if for no other reason than to avoid potential pathological or boundary states that may not have been well exercised.

(FYI, I recall a weird case where copying the entire contents of one particular release of an OpenVMS documentation CD using a specific model of CD drive resulted in a long seek which confused the seek logic in the drive. The COPY failed, but would be OK if individual files were copied. Although this had nothing to do with placement of INDEXF.SYS, it shows how particular access patterns can result in unexpected errors)

A crucible of informative mistakes

The logical middle won't be at the half-stroke position. Depending on the numbers of platters and on numbers of sectors present at each track, the logical middle could easily be at the extreme end of a head stroke.

With four platters of equal capacity and consistent linear block allocation per track, the logical middle will be at the physical edge of the disk; in the "worst" position.

Back when my site was using VDDRIVER to split large RAID volumes into virtual drives, placing the index file at the beginning made packing the large contiguous files into the LBN range much simpler.

Disks are so large now, there's little relative space penalty for simply initializing the volume with 16 million headers.

I'm looking for marbles all day long.

we used to init a little before the middle so the bulk of the index would reside over the real middle. now I just
preallocate the headers & directories, happy
the days of rm05's are over.

Art,

My experience is that the output disk of a BACKUP/IMAGE restore uses the space after the index before using the space before the index. It doesn't try to allocate "nearest" to the middle. My guess is that it has a pointer to the next free location, and that pointer is initialized to the first free space after the end of the Indexf.sys file.

This can be verified by using DFU report/graph immediately after restoring a disk. It is most obvious if the disk is 50% full or less.

The point is that when doing an image restore, the lowest available blocks are not what is chosen. I can't say whether the initial free space after the indexf.sys is initially larger or smaller.

One other note: File positioning information is not preserved by an image backup, even when going to a disk of the same size (this is my observation from BACKUP 7.2-2 system, I haven't tried on 7.3-2 or 8.3). Also, if you have large files that must (or you want to be) contiguous, put them in a directory that will be restored early. For example, if you have a contiguous file that is 40 percent of the volume, you will probably want it in a directory like [000BEG] so it will be processed early. Or avoid the problem by using /INDEX=BEGINNING.

Regarding your question about EVA8000 and positioning the /INDEX: Since the allocation of psegs to drives is under the control of the EVA, even if you preallocate as suggested by Hein, I am not certain that any order you have will be preserved after "leveling" occurs on the EVA.

Having the index in the default middle position shouldn't affect performance one way of the other.

Supposedly, the EVA has or will have the ability to "shrink" volumes, because Windows servers have the ability. That may be a reason to initialize/index=begin and preallocate headers, just in case you ever want to be able to shrink a volume (if it ever is supported by VMS, or using Hein's proposed method.) This assumes you can use a defragmenter or something else using movefile to free up all allocations in the region to be truncated.

I am planning to user/index=begin when I move from HSZ to EVA, and to change the clustersize to a power of 2.

it depends

>> My experience is that the output disk of a BACKUP/IMAGE restore uses the space after the index before using the space before the index.

Odd, but not inconsistent with my observations in:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1136467
There I show /IND=BEG and back/image filling from low LBNs onwards.

Jon>> The point is that when doing an image restore, the lowest available blocks are not what is chosen.

They are, with INIT/IND=BEGI an BACKUP/NOINIT

Jon>> File positioning information is not preserved by an image backup,

WHich is just as well! Many image backups are specifically done to de-frag, thus move extents.

Jon>> Having the index in the default middle position shouldn't affect performance one way of the other.

So that argues for using BEGIN (or END) if it has no performance value, then it has no value.

Cheers,
Hein.

You can inspect disk layout in the defragmenter with /int=decw. And click on the map to get file details.

In my case, it shows a mess for most disks (all kind of raids on ma8000) and this while we defragment every weekend. But without stopping anything.

May be it would be a good idea to stop everything during a weekend a do a defrag with hotfile placement.

I also noticed that on a disk with db files that were created with /contig were not placed in a serial manner. The first one in the beginning, the 2nd one at the end of the disk. The 3rd was created /nocontig because the index in the middle prevented /contig. And resulted in a piece following the 1st file (before the middle) and a 2nd directly after the middle. Thus we have holes before the middle and before the last file.

fwiw

Wim

Wim

I started with a fresh defragmented empty disk of 71 MBl. I created in a loop contig files of 10 Mbl. After 5 this was impossible because contig space was gone.

I discovered in defrag map that the files were created with an interspace of about 7MBl.

No idea why.

Wim

Wim

Dean ... 10 points for mentioning RM05's!! I used to work for Control Data - the OEM for those drives - the CDC 9766. So many hours of my life I'll never get back - isopropyl on the punch card, swiping the new head in an "S" motion to clean them ... aligning heads with the 'scope and the servo pack ... only being able to do two or three before you had to put the shroud back on to let it come back up to temp ... all for 300MB!! Good times!!!

Anyways, when it comes time to init my EVA volumes, I will consider all the suggestions provided here ... index at the beginning and lots of headers and directories.

Cheers all,
Art

Art,
so you worked on the rm05's, wow! that
goes back there. I coined the phrase disk
herpes with those. how many times I'd see
the operators put a bad disk in a good drive, and make it a bad drive. then put
a good pack into the new bad drive. on and on. when they were working, they were pretty
good drives. I've included my initdisk, with a fix to select index=begin. tweak as needed it preallocates headers and directorys.

Dean

Several comments in response to Hein's responses to my note.

When I stated that file placement isn't preserved, I meant explicit file placement retreival pointers are not preserved by a backup/image.

Specifically, a file placed with something like

$ cre/fdl=sys$input $5$lda1:[000000]RESERVED.SPACE
file;allocation 10000;contiguous yes;area 0;EXACT_POSITIONING yes;position logical 190000
Exit
$ dump/head/bl=c:0 $5$lda1:[000000]RESERVED.SPACE

most removed for brevity

Map area
Retrieval pointers
Placement control: Exact
Count: 10000 LBN: 190000

Checksum: 8800
$

After the backup/image this file is not treated specially, other than to remain contiguous (if possible).

In my experiment, the new file had the following as retrieval pointers:

Map area
Retrieval pointers
Count: 10000 LBN: 101086

Checksum: 40955

Also, my comment "Having the index in the default middle position shouldn't affect performance one way or the other." was in the context of an EVA controller. On single spindle device, it probably does make a difference, but whether you would notice it depends on how frequently the file headers are referenced while accessing other files on the disk.

I'll respond to the file placement done by backup/image in another note.

Jon

it depends

Wim Van den Wyngaert>>>>I started with a fresh defragmented empty disk of 71 MBl. I created in a loop contig files of 10 Mbl. After 5 this was impossible because contig space was gone.

>I discovered in defrag map that the files were created with an interspace of about 7MBl.

>No idea why.

-------------

My guess is that this was in a cluster. Other nodes "reserve" a range of available free space so they don't have to bother coordinating with the other members when allocating extents. If a node requests contiguous allocation, and can't satisfy it, it will force the others to flush and try again. However, once the gaps are there, they in effect reduce the "largest free extent".

You can use explicit placement to force the other nodes to relinquish the space they have reserved but not used. See my previous note for one possible say to do this. Using the output from defrag show /free will help you find where to place the file.

it depends

In my response from Jun 18, 2007 19:29:20 GMT, I stated:

--------------------------------------------------------------------------------
The point is that when doing an image restore, the lowest available blocks are not what is chosen. I can't say whether the initial free space after the indexf.sys is initially larger or smaller.
--------------------------------------------------------------------------------

I've done some experiments with LD V8.3 on VMS 7.3-2 with patches current as of Mar 24, 2007.

It appears I was not correct in my assumption of how space was allocated by backup/image, where I guessed that it kept a pointer to the highest used space, and then allocated sequentially from there. The clue was that some files were copied to very low LBNs.

I now think Backup /image uses the smallest areas available first, so it can leave the largest free extent when it is complete. The following report is from DFG.

By the way, well worth installing Defrag just for the reporting, and no license is needed for that. An example installation is included in the logfile attached.

The following is from a 200,000 block LD device:

$ init lda3: /cluster=1/header=500 itrc
$ mou/ov=id lda3
%MOUNT-I-MOUNTED, ITRC mounted on _$4$LDA3: (SIGMA)
$ defrag show /location/file=4 /free lda3:
Disk File Optimizer for OpenVMS DFG V2.7
Â© 2002 Compaq Information Technologies Group, L.P

F r a g m e n t a t i o n R e p o r t

DISK$ITRC 19-JUN-2007 17:39:15.99

The fragmentation index is 1.0
1 - 20.9 is excellent
21 - 40.9 is good
41 - 60.9 is fair
61 - 80.9 is poor
81 - 100 indicates a badly fragmented disk
Approximately 0.8 (out of 80.0 possible) is due to file fragmentation
Approximately 0.2 (out of 20.0 possible) is due to freespace fragmentation

Freespace Summary:
Total free space: 199425 blocks
Percentage free: 99 (rounded)
Total free extents: 4
Maximum free extent: 98965 blocks, LBN: 1035
Minimum free extent: 514 blocks, LBN: 100571
Average free extent: 49856 blocks
Median free extent: 98914 blocks

Freespace Extents:
LBNs 2 to 1033 (1032 blocks free)
LBNs 1035 to 99999 (98965 blocks free)
LBNs 100571 to 101084 (514 blocks free)
LBNs 101086 to 199999 (98914 blocks free)

File Fragmentation Summary:
Number of files (with some allocation): 4
Total file extents on the disk: 7
Average number of file extents per file: 1.750000
Median number of file extents per file: 1

Most Fragmented File:
[000000]INDEXF.SYS;1 (4 extents)

1 file with 4 or more extents:

[000000]INDEXF.SYS;1 (4 extents)
VBN 1, LBN 0 to LBN 1 (2 blocks)
VBN 3, LBN 1034 to LBN 1034 (1 blocks)
VBN 4, LBN 101085 to LBN 101085 (1 blocks)
VBN 5, LBN 100052 to LBN 100564 (513 blocks)

$

In this case, the 98,965 block free extent starting at LBN 1035 is the largest, and backup/image apparently preserves that until the smaller pieces have been used.

When I initialized with /index=80000 the free space at the end of the volume was preserved.

Note that backup/image is writing to a disk that is mounted foreign, thus the XQP is not involved in the allocation of blocks. Backup itself is in full control of the allocation. In the attached log, you can see that a non-image backup of files to a newly initialized disk results in a different placement, which appears to be based on first available, but this was a special case, as the disk was mounted privately and was just initialized. In volumes mounted cluster wide, other nodes can reserves a cache of free extents to optimize allocations from a time perspective.

I am attaching the log file of my experiments, if you are interested in seeing output of DFU report, etc.

I also ran into an issue with OpenVMS 8.3 factory installed software (without patches) and LDDRIVER V9.0. Doing a backup/image of a 200,000 block LD to another 200,000 block LD resulted in a disk that could not be mounted.

$ mou/for $5$lda3:
%MOUNT-I-MOUNTED, ITRCMID mounted on _$5$LDA3: (SIGMA)
$ backup/image $5$lda1: $5$lda3:
$ dism $5$lda3:
$ mou/ov=id $5$lda3:
%MOUNT-F-FILESTRUCT, unsupported file structure level
$ help/mess FILESTRUCT/fac=mount

FILESTRUCT, unsupported file structure level

Facility: MOUNT, Mount Utility

Explanation: This message occurs on pre-Version 7.2 systems when you
attempt to access a disk that was initialized on a Version 7.2
or later system. Version 7.2 extends the size of the BITMAP
field and the increased size is incompatible with earlier
versions.

User Action: Check the size of BITMAP.SYS on the disk you want to access.
If the size is 256 or greater and you want to access the
disk from a pre-Version 7.2 system, you must copy the data
to a disk with a BITMAP.SYS that is less than 256 blocks.
If you use the DCL command BACKUP/IMAGE, be sure to use the
/NOINITIALIZE qualifier.

$

Doing a backup/noinit didn't help.

More details in the attachment if you are interested.

The same sequence of commands works on a VMS 7.3-2 system with patches current as of Mar 24, 2007.

I haven't determined the cause of the problem, I have dumps of the homeblocks in the logfile.

I see there is a patch to backup, and I think that is more likely to be at fault than LDDRIVER.

it depends

Jon,

I don't think this is an LD issue. I could reproduce it with LD V8.2 on VMS V7.3-2 too. Also reprodcued it on Alpha V8.3 with LD V9.0, and on Itanium V8.3 with LD V9.0.

I remember that I've seen something like this in the past, when creating small containerfiles and initing them. I'll see if I can find something about that in my mail, as I remember sending a certain person in VMS engineering mail about that.

If you leave out /CLUSTER=1 on the INIT command it works, so my guess is that it's something in INIT code which is used by backup.

Small reproducer:

$ ld create d1/size=100000
$ ld create d2/size=100000
$ ld connect d1 lda1
$ ld connect d2 lda2
$ init lda1: /cluster=1 /system /head=500 /user=itrc itrcdemo
$ mount lda1: itrcdemo
$ backup sys$loadable_images:*.* lda1:[SYS$LDR]/own=system/trun/ver
$ mount/for lda2
$ backup/imag lda1: lda2:
$ dism lda2
$ mount/over=id lda2

Jur.

Seems like this is the issue:

VMS82A_BACKUP-V0200:

5.2.2 %MOUNT-F-FILESTRUCT Error When Mounting Image Backup

5.2.2.1 Problem Description:

After restoring an image BACKUP, the disk may fail to mount with a %MOUNT-F-FILESTRUCT error

5.2.2.3 Problem Analysis:

BACKUP now preserves the volume expansion size, an attempt to restore a save set with expansion size smaller than 25MB will result in failure to mount the disk.

Jur.

Jon,

Did the same test on a non-cluster (7.3).

Same result. Between the first file and the 2nd file a gap. I init the disk with index in the beginning. Same result.

So not because of in cluster.

Wim

Wim

Wim,

I was able to reproduce your findings, and even when the disk is mounted privately to my process.

In fact, the only way I was able to get the files to be created without specifying exact placement, was to dismount/mount the disk before each file creation.

I am not sure what the reason for the gaps is, I still think it is related to a "cache", because no gaps are left when creating small (10 block files). It's as if there is a lookaside list for small requests.

See attachment for reproducer and log of a run.

Jon

it depends

Jur,

Thanks for info about VMS82A_BACKUP-V0200, I saw there was a patch for V8.3, but

ftp://ftp.itrc.hp.com/openvms_patches/alpha/V8.3/VMS83A_BACKUP-V0200.txt

Has only a description of a bad location of a .CLD and a reference to VMS83A_BACKUP-V100.RELEASE_NOTES for problems addressed in previous patches. My guess is that VMS83B will fix the same problem for VMS 8.3.

Jon

it depends

Jon,

It is probably the extent cache getting in the way,

Try again with MOUNT/NOCACHE ?

Sorry, can not try myself.
Just stealing minutes between sessions @HPTF in Vegas.

Hein.

Hein said:
---------------
It is probably the extent cache getting in the way,

Try again with MOUNT/NOCACHE ?
---------------

Yes, that worked.

I've attached reproducer with example run log.

Summary:

If you need to create large contiguous files, and you want to preserve the largest remaining contiguous free space, you will need to avoid the extent cache.

The easiest way, is to mount /nocache, create your files, and remount /cache (default).

If you can't dismount, you can create files using explicit exact placement with fdl. But if the disk has activity on it, the free space may change between when you determine where to place the file, and when you attempt to create it.

it depends