From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re: Re: Bound volume sets: are they a bad idea?
Date: 14 Nov 92 13:18:25 GMT
Distribution: world
Organization: The Internet


	[An earlier article mentioned ... "considering the idea of taking two
	600Mb disks and binding them into a 1.2Gb volume set."  It continues:

	"As far as I can reason it out, the pro is some degree of load
	balancing  between the disks, and no management hassles sorting out
	what to put where.  The con is a halved MTBF on the bound set. Backup
	shouldn't be a problem,  both together will fit on one DAT."

	Mr. Brydon responds:]

	Several other posters have mentioned the MTBF aspect.  Also, keep in
	mind that you are taking 2 'large' volumes and making them into one.
	This effectively increases the size of the cluster factor.  If it is 4
	on one of these disks, it will be 8 on the volume set

Eh?  What makes you say this.

							      (Same with a
	stripe set, too).

I quite agree that it MIGHT happen on a stripe set.

In theory, you can make the clustersize anything you like.  However, there is
a limitation, the deeper origins of which escape me a the moment, but they
manifest themselves as requiring that BITMAP.SYS be no more than 255 blocks
long.  BITMAP.SYS contains one bit for ever cluster on the disk; a bit is
set if the cluster is in use.  At 8 bits per byte, 512 bytes per block, and
255 maximum blocks, there can be at most 1,044,480 clusters on the disk.
A million blocks is roughly a 500Mb disk; no larger disk can have a cluster-
size of 1.  A 600Mb disk must have a clustersize of at least 2; a 1.2Gb disk
at least 3.  (These numbers might be one higher because a number like 600Mb
is not exact - is it really 605*2^20, or what?  The actual formula for the
minimum cluster size is just blocks/1044480, rounded UP.  Note, BTW, that
because of the rounding up, it is not in general true that the minimum
clustersize double when you double the number of blocks - it can be one less.
This is a significant effect when the clustersizes involved are small.)

Members of a bound volume set retain their own "block address spaces" and
their own bitmaps.  Binding volumes doesn't change the limit on the cluster-
size.

A stripe set, on the other hand, looks like one big disk.  There is just one
copy of the bitmap which must cover the entire set.  Hence, binding two
600Mb disks into a 1.2Gb stripe set would, indeed, increase the minimum
supportable clustersize.

			   So if you have a lot of files that are small (ummm,
	in fact, even if you don't), you will be wasting an average of 4
	blocks per file.  Even if this is not a concern in terms of disk
	space, remember that disk read/write requests are done in clusters,
	not in blocks.  If your application wants one block from disk, it
	reads in the whole cluster.

This is just plain false.  While it's true that, IF you want to read ahead,
reading the rest of the cluster is a good idea, there is nothing in the
disk drivers and certainly not in the hardware which cares about cluster
boundaries.  In fact, this file-system-level abstraction doesn't even exist
at this level.

				     Even if most of the cluster is 'unused'
	space on the disk.

							-- Jerry

Newsgroups: comp.os.vms