To: Gary Meyer
From: Glenn Everhart
Re: Thought you'd like some docs on what virtual disk packages
exist. I whipped up the software worm very recently.
------
The following varieties of virtual disks exist in demonstratable
states:
VDdriver: virtual disk on contiguous disk file. Fast performance
	and allows  volume ACLs and custom cluster factors among
	other things.
VQdriver: Virtual disk on two contiguous disk files, mirrored.
	This driver allows volume shadowing (and has a transparent
	catch up) of two virtual disks. (Like VDdriver, the contiguous
	files can be entire volumes or sections of volumes; the storage
	can be specified by logical block and size, or by filename.
	On write, both containers are written (if present); on read,
	the container with the closest "last accessed LBN" is used
	to get the data.
FQdriver/FDdriver:
	This driver allows a host process to handle actual storage,
	making that process' storage appear to be a locally attached
	disk. Host processes implemented include:

	* Remote virtual disk over DECnet.
	* Memory disk using the host process' virtual memory. The
		actual memory consumption is determined by the process
		working set.
	* Virtual disk based on a file which need not be contiguous.
		This file may be accessed across DECnet if desired.
		RMS read/write do the low level I/O in this case.
	* Virtual disk shadowed by memory region. In this case all
		writes go to both the memory region and a not necessarily
		contiguous file. Reads come from the memory area.
	* Virtual disk on encrypted file. The encryption algorithm is
		an XOR with very long string, which is very fast and
		tends not to inspire such unwanted interest on the part
		of export agencies when done commercially. The bit
		string is computed from the key, and this computation
		is relatively hard to reverse.

The following varieties are not available to the public:
	* Virtual disk, read-only, made from physical backup. A physical
		VMS Backup image (or any block-for-block disk dump as
		well) are presented to VMS as a read-only disk. Large
		cache allocation helps speed performance up.
FVdriver: This driver uses a contiguous file for its storage as a disk,
	and on read its' operation is exactly like VDdriver. On write,
	it buffers writes and notifies a journalling "host process"
	when the buffer fills. Because this is done from start-IO,
	if an FVdriver unit is MSCP served to a cluster, the journal
	will automatically capture all writes from anywhere on the
	cluster. the journal preserves all write data, timestamped
	with the 64 bit VMS time, and labelled by block it comes from
	and byte count. In this way, a backup of an FV: unit plus the
	journal can reconstruct that unit as of any moment in time
	from the backup time on, and separate backup need not be
	done so often.

FWdriver: This driver and fdhostworm work together to form a software
	"worm" device. The driver returns I/O errors on attempts to
	delete files, and the host process will inhibit overwriting
	blocks above a "fence" LBN which is user settable (/FENCE:nnn),
	so that a normal index file and directories can exist below
	the fence LBN, but above it, any attempts to overwrite journal
	files and the like are rejected.
	  The storage is on a not necessarily contiguous disk file
	somewhere on the DECnet, and the storage file is encrypted to
	prevent traceless modifications. To do volume maintenance it
	is necessary to use the fddriver crypto-disk host to access
	the container, which will treat it as a normal disk. This
	WORM disk is vulnerable to wholesale corruption, but not to
	traceless mods.