From:	SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 28-OCT-1993 11:27:30.96
To:	EVERHART
CC:	
Subj:	Virtual disks

Date: Tue, 26 Oct 1993 20:39:21 -0400 (EDT)
From: EVERHART@arisia.gce.com
To: INFOVAX@arisia.gce.com
Message-Id: <931026203921.5e@arisia.gce.com>
Subject: Virtual disks

There are lots of virtual disk drivers on the DECUS sig tapes & CDs
for VMS. The ones I use most make contiguous files or contiguous disk
regions look like separate volumes.

Disadvantage:
There are multiple index files, so seeks from one to another can add
a bit of time to disk access if you're accessing several virtual disks
on the same physical disk at the same time.

Advantages:
You can tailor cluster factor, add volume ACLs and protections, you can
make groups the owners of disks and let the groups fight for disk space
on a virtual disk among themselves (letting the system manager out of
the battle). You can arrange for backups to fit on tapes more easily
and use virtual disks to organize files. You can separate the extremely
high activity files (e.g. on news disks) from the rest of your system
file activity so the rest of your disk doesn't get fragmented as fast.
You can take any disk area (e.g. sysdump.dmp) and make it available for
temporary scratch storage. You can use a shadowing virtual disk driver
(those exist too; look at VQdriver and WQdriver on the S93 tapes)
to shadow a virtual disk, or use it with a remote virtual disk (those also
exist) so as to shadow across a network. When reading files from another
site, you can put them on their own file structure, and when done with it
you just delete ONE file to remove it all. Many other tricks exist.

The VDdriver imposes a completely negligible overhead on I/O. FQdriver
adds a bit more since it uses a process to do the actual I/O, but is still
very fast. Incidentally, VDdriver and FQdriver exist for Alpha also.

I've used them for years.

It is possible in a cluster with mscp-serve-all set to get into some
race conditions occasionally where a cluster member crashes and comes
back, such that a disk may not be available, so I hear. If you do
manual serving, or if you use the "cluster" version of the driver so
each CPU has its own copy, this isn't an issue.

The major problem people seem to have is that the kit is not VMSINSTALlable
so you have to think a bit about how to do it. You use sysgen to connect
the driver units, and a privileged image to associate the driver units
with storage. 

One thing to be careful of: VDdriver does not keep the container file
locked, so you must ensure no defragger moves it. I tend to set the
files /NOMOVE which protects them from JUICER2, but if you use another
defragger, be sure to set it not to mess with your container files.

I've found that setting some VD units up at the top of a disk is real
handy to fix it so the part I boot from is in the first 1 GB of a larger
disk.

Also, Paul Sorensen's CDdriver can add device cache to any virtual disk
(or real one connected in one place); works well.

There are shadowing virtual disks, remote virtual disks, virtual disks
on container files, contiguous or not, encrypted or not. There is a start
at a compressing virtual disk there which I never quite got done with
and various types of journalling virtual disks and the "BOH" virtual
disk, a virtual disk that shadows a container file with a memory region
so that reads all come from memory, writes going to memory and file.

There are other tricks too.

Remote virtual disks work real well for remote backup (you make the
remote disks look local to the machine with your tape drives and
run backup there). I've recently fixed it so the disks survive temporary
loss of network connection just fine, for both the Vax and Alpha
versions. 

Virtual disks are much more flexible than the device partitions one sees
in older OSs like RT-11 and Unix. You can make volume sets out of them
just like real volumes. About the only important thing they won't do
is let you boot from them.

There's a memory virtual disk that uses a PROCESS' virtual memory
too; this works nicely in that the space needed is determined by how
much space the process takes, and it doesn't mess up the VMS algorithms
by grabbing and holding large amounts of memory when process contention
gets bad.

Glenn
Everhart@Arisia.GCE.Com