SD - Striping Driver

This driver and assign utility allow disk striping on vms
without the expense of the DEC solution. You can decide to
build sddriver as MSCP serveable or just put a copy on every
node in your cluster; the underlying disks must in that case
be available (possibly you serve them). The logic to let you
shadow one of these stripesets is there too.

   You decide if sddriver is serveable or needs to be on each
node by defining clu$$str and defining sdalcls to some value
(below 255 and different from all allocation classes in your
cluster). If this is not defined, you get the regular, serveable
driver (though ucb$l_media_id might need to be changed to
get thedevice name right everywhere). The asnsd image is the
same in all cases.

   SDdriver works by taking your I/O request and generating
subordinate requests so that its storage is split across between
2 and 16 equal-sized storage areas in chunks of size you specify.
The idea is that for an N block "chunk" (or "granule") size,
the virtual disk has these N block chunks scattered across
its containers in round-robin fashion. You specify a number of
"reserved" blocks at the start too. The first reserved block
(if you specify at least one) is used to hold information about
the stripeset on disk, so that when setting up the stripe set
you will be prevented from many mistakes of associating the
storage containers in the wrong order, or off the wrong
devices. Note that 16 containers is essentially all the info
that fits in one block, which is why a stripeset cannot be
larger.

   Suppose you have three containers holding 10000 blocks
each (which can be any set of contiguous blocks on any disks).
If you say there is 1 reserved block and chunksize is 10 you
get a mapping that looks something like this:

Block # on SD unit		Where it is
0-9				container 1, lbn 1-10 (since 1 reserved blk)
10-19				container 2, lbn 1-10
20-29				container 3, lbn 1-10
30-39				container 1, lbn 11-20
40-49				container 2, lbn 11-20
50-59				container 3, lbn 11-20
60-69				container 1, lbn 21-30

and so on

Note that LBN 0 of containers 1, 2, and 3 are reserved blocks; the
first container has stripeset information stored here. The size
of a chunk can be whatever you like, though if you make the chunk
size too small, you generate lots of extra subordinate I/O packets.

The driver does not ever need to copy data into memory as the DEC
one does if the buffer isn't page aligned, but it will not combine
chunk I/O. Thus if you had chunk size=1 and a large I/O trying to
move 64 blocks, you might have 64 subordinate I/O packets used
instead of the 3 the DEC driver would use. However, in practice
this is a very rare case, and the overhead of a new IRP is less
in any event than copying all user data. Most of the time SDdriver
will at least equal the DEC striping driver's speed; sometimes it
can top it.

You can assign up to 2 containers per call to the ASNSD image,
and call it multiple times to get up to the max of 16 (limited by
space to store info in the UCB). The containers can be specified
either as contiguous files anywhere on your system (not across a
net...use remote virtual disk to make remote disks appear local
first if you must stripe such things, which is not recommended),
or as sections of disk by logical block (up to and including an
entire disk). These can be mixed and matched, but should be the same
length in each; the mapping algorithm makes this assumption.
It is perfectly permissible to put SD units on top of VD virtual
disks or vice versa, or even to do weird stuff like creating a
giant striping disk, then creating a bunch of virtual disks with
VDdriver on it, then making a volume set out of the virtual disks
so you can have cluster factor=1 in all your storage. The overhead
of all this is quite negligible, even though it sounds strange,
and it affords a way to achieve the file structure characteristics
of a volume set while spreading the I/O load evenly across many
physical disks.

The ASNSD image associates actual storage with a unit of SD.
Its call is

$ ASNSD/switches SDAn: disk1:[dir1]file1 disk2:[dir2]file2

or

$ ASNSD/switches SDAn: disk1: disk2:

		if logical block specs are being used.

Switches are as follows:

/ASSIGN		Assign an SD unit (as opposed to /DEASSIGN)
/APPEND		Add more units to a partly specified SD unit
		(used to specify 3rd through 16th containers
		after specifying the first 2 in initial call)
/DEASSIGN	Deassign an SD unit. Takes the unit offline and
		causes it not to send any more I/O to its containers.
/CHUNKSIZE:nnn	Sets striping chunk size to nnn blocks (decimal)
/GRANULE:nnn	Synonym of /CHUNKSIZE:nnn
/RESERVED:nnn	Sets number of reserved blocks at the start of each
		container. If 1 or greater, the ASNSD image checks
		the assignments to ensure you don't collect things
		from the wrong places or in the wrong order (unless
		you use the /NEW switch).
/NEW		Says this is a new stripeset, don't look at the
		first reserved block to validate we have the
		assignments the same as last time.
/ENABLE		Says that the disks specified here are the last in
		the stripeset, so put the unit online and valid if
		all looks OK. You use this on the last setup call
		to ASNSD to tell it when all the containers have been
		specified.
/SEC32		Set the geometry of the resulting storage to be
		32 sectors/track, 32 tracks/cylinder, and as many
		cylinders as fit in the total size. INIT and MOUNT
		need a geometry, even though you don't really do physical
		I/O to a striping disk.
/SEC64		Sets the geometry to be 64 sectors/track, 1 track/cylinder,
		and as many cylinders as fit.

	In addition to these, if the resulting disk is under 64000 blocks
	it will use a 1 sector/track, 1 track/cyl and "N" cylinder
	geometry, and if the size matches a number of common disk types,
	the geometry will be set to that of the matching single disk
	type. Thus, a resulting disk of 1008000 blocks is the size of an
	RP07, so it would be given RP07 geometry (630 cylinders, 32 tracks
	per cylinder, 50 sectors per track).

The following switches are used to specify storage by starting logical
block and size:

/LBN:nnn	Start LBN for first container on command line
/LENGTH:nnn	Length of first container on command line
/SLBN:nnn	Start LBN of second container on command line
/SLENGTH:nnn	Length of second container on command line

Where these are present, only a device name need be given on the command
line; a file is not necessary. Either, both, or neither of the containers
can be specified this way on a given command line. However, it is required
that both LBN and length be specified together. There are no defaults for
these. Remember that a disk starts at LBN 0 if you use this to specify
an entire disk for the striping driver.

Glenn C. Everhart
Everhart@Arisia.GCE.Com