From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re: REPOST: Parameters for Diskperformance
Date: 11 Jan 93 12:52:08 GMT
Organization: The Internet


	..... I think the first time I selected distribution:world, so here it
	      comes again......

Well, I don't recall seeing this before, and I'm in the world somewhere....

You also carefully included a complete mailing address (in Switzerland),
plus two phone numbers - twice; but you failed to include an Email address,
so I can't reply directly (the return address was some news server).

	We will install a new RF73 disk during the next days. And I'm
	rembering there are some parameters like clustersize and so on wich
	affect the performance of disks. But unfortunatly I don't remeber were
	I saw it. I tried the manuals, but its a hard work to check all.
	Perhaps some kindly soul has it handy and may help me.

	Our konfiguration is as follows:

	MVS3300 and MV3400 Dualhost over DSSI, all Disks on DSSI
	1 RF71 		System
	1 RF71		Some Applications (Mailer and Network SW)
	1 RF72		VMS Userfiles  16'000 files in 800 directories
	1 RF73		MSA Files  55'000 files in 6'000 directories

	MSA has always a lot of files open

	We are tigth on the following resources: IO and CPU, we have plenty of
	memory (each MV 44 has Mbytes) and enogh diskcapacity (50% used).

There are relatively few parameters you can adjust, and of those almost none
have anything to do with performance.

Clustersize is, indeed, one of the few.  The tradeoff is simple:  Larger
clustersizes produce better performance (files that have larger contiguous
pieces) at the cost of disk space.  Since file allocations are always rounded
up to the nearest multiple of the clustersize, if the cluster size is C,
the expected space wasted per file is (0+1+...+(C-1))/C = (C-1)/2.  On the
other hand, with this clustersize, every C blocks of the file are always
contiguous and can be read quickly.  You really have to look at the expected
usage of the disk to make a rational choice of clustersize.  If the disk will
contain a very large number of small files, it makes little sense to choose a
large clustersize:  Many of the files will be smaller than the clustersize and
would have been contiguous even with a smaller clustersize, and even on a very
fragmented disk it's usually possible to find a couple of adjacent clusters
for the slightly larger files.  On the other hand, if the disk will contain
relatively fewer large files, the space lost due to rounding won't be signifi-
cant but the additional contiguousnous will help.

The only other consideration in choosing the clustersize is that you should,
if possible, choose a clustersize that evenly divides the number of blocks
on a track; or failing that, on a cylinder.  This ensures that clusters don't
cross track (cylinder) boundaries.  I don't know the relevant numbers for an
RF73, but they'll be in the specs.  Make sure you use the number of blocks
that will be USED; there will be some spare ones for replacing bad blocks.

You can move the index file from its default position in the center of the
disk by using the /INDEX qualifier of INITIALIZE.  However, the default is
the position that gives the best performance in normal usage; moving it
elsewhere is only useful when you are formatting a disk that is intended to
contain a really huge file (larger than half the disk),

The /WINDOWS qualifier lets you change the number of file mapping pointers to
be used when the disk is mounted.  Larger values can give you better perfor-
mance at the cost of memory - the window is effectively a cache - but the
value you specify here is only a default; the MOUNT command can override it.
So it's something you can always change later.

Specifying /NOHIGHWATER will have a minimal effect on performance unless your
use of the disk is fairly unusual.  (Only if you have programs that frequently
write to blocks of a file well beyond the current end of the file - i.e.,
programs that leave unwritten "holes" in a file - will you be likely to see an
effect.)

Most of the remaining parameters you can set have to do with pre-allocation
of objects for anticipated later use.  For example, the /DIRECTORIES qualifier
sets the size of the MFD - useful if you intend to create a large number of
top-level directories.  /MAXIMUM_FILES and /HEADERS control the maximum number
of files you will ever be able to create on the disk, and the number of file
headers to pre-allocate.

Beyond this, you can increase various cache sizes through SYSGEN parameters
like ACP_MAPCACHE.  These will apply to all disks in the system, and don't
require any change to the disks themselves.
							-- Jerry