show device/window

[Wim Van den Wyngaert]

I have a batch job creating a log file.

Defragmenter tells me that it has 546 extents.

dump/header reports 76 retrieval pointers.

If I do a show dev /window, I see 1 window, total size 144.

As I understand it, I have 76 extents of logfile, all other extents are contiguous with these 76. There should be 11 windows of size 7.

Why is show dev/win showing 1 ?

[Jan van den Ende]

Wim,

Maybe was the disk INITed with a greater /WINDOW (but IIRC the max for that is 80, you have 144)
What is your SYSGEN param ACP_WINDOW ?

You DO get a big performance gain if you manage to get all extents in 1 window, and you reach this gain by setting ACP_WINDOW to 255. The price is memory, can even be tens of kilobytes if there are many fragmented files open simultaniously.
In modern times EVERY VMS system should have this, and you can forever forget about it.

( Engeneering: wouldn't it be a good idea to change the default ? )

Jan

[Willem Grooters]

dump/header reports 76 retrieval pointers>

When the file was created, at least one cluster was allocated and filled. If full, the next cluster would be allocated to that file. Still, there is one fragment - and still one retrieval pointer, but one next more extent.
There comes a point that the next cluetsre to eb allocated is already allocated to another file, so another cluster has to be allocated, somewhere else on the disk. This is the next fragment - and the next retrieval pointer. And so on, and so on.
In the end, the file has been extended 545 times, and results in 76 fragments on disk.
Without more information (indexf.sys!) you cannot tell how these fragments are spread over the disk.

Next is just a wild guess but for what I knwo of VMS and RMS, I think roughly accurate (I hope).
Number of windows is the number of channels open to that file by that particular PID, and sixe the number of blocks kept in memory (cache or in the process's buffer).
That menas: the process will see just 144 blocks of the file at a time. If you had opeend another channel to the same file in the same PID, you would have 2 windows.

Willem

[Willem Grooters]

Jan,

I just did the same thing on "my" disks and found most 80 and 144, some 112 and 128. Indexf.sys has 192 as windowsize.
Some disks have mostly 80, others mostly 144.
A quick scan (not extensively!) revealed:

* executables ==> 80 (at least: most of them)
* datafiles, .COM, .LOG ==> 144
* indexf.sys ==> 192
* sysdump.dmp ==> 128

As far as .EXE are involved: just a VERY few have a windowsize > 80 (112, 128, 144)

BTW: These numbers look the same for ODS-5 and ODS-2 disks. I don't know if clustersize and extend quantity matter.

[Jan van den Ende]

Willem,

you woke me up.

The story is more or less yours and mine multiplied.
Yes, each extent pointer is stored in the header. When the header is full, you get an extension header (etc...)
And what the a WINDOW is holding, is a number of extension headers...
So, Wim, if you have 1 window, that means the number of HEADERS is less then the window-size. So, you have to do quite a lot of fragmenting to get your headers not fitting in the window view, BUT IF YOU DO, THE PENALTY IN PERFORMANCE IS QUITE SEVERE!!
(that's to say, if you move randomly through the file).

And now I hope I have not forgotten still more...

Jan

[Hein van den Heuvel]

> Defragmenter tells me that it has 546 extents.
> dump/header reports 76 retrieval pointers.

I would like to understand that better.
1 fragment = 1 extent in my book.
546 extends would mean several file headers... that sucks.
Are you ignoring extention headers?
Maybe you can show a little bit of a header dump?

I really thought I remembered that adjacent extents would be 'glueed' together by the xqp in the file header, not just in the window control block.

For sequental read/write (like what you do to a batch job log) is really does not matter much whether the window holds all pointers or not, as you never come back and just use 1. Still, every time a pointer is not there, a header needs to be visited (in the header cache, possibly needing an IO).
(btw... There is only one channel/file)


Instead of worrying about how to deal with windows and fragments, you should perhaps focus on trying to avoid them. How about
SET RMS/SYST/EXTE=2000 ?
or
SET VOLUME/EXTE=2000 logfiledisk:

Myself I am a big fan of using a cluster size of 512 or 1024 or so.
Obviously this may be too costly for applications with hundreds of thousand of files on a disk, but if you have less than 10,000 files, it may be worth the waste.
Just do your own calculation: cluster size = acceptable_blocks_wasted divided by largest_number_of_files_expected.
It does not have to be precise.
It does not have to be a multiple of 2.

Hope this helps some,
Hein.

[Wim Van den Wyngaert]

Hein,

Again, just trying to understand things.
I posted the output of a simular file.

Wim

[Hein van den Heuvel]

That looks broken. I would trust DUMP/HEAD and distrust the DFO data. Odd. Very odd.

Hein.

[Willem Grooters]

Wim,

Just to get the whole picture, can you supply output of

$ SHOW DEV/FULL

and

$ DIR/FULL

Willem

[Wim Van den Wyngaert]

Voila