Volume Manager
Volume Number: 2
Issue Number: 4
Column Tag: Advanced Mac'ing
Nested Volume Manager DA 
in Megamax C
By Mike Schuster, Adobe Systems Engineer, MacTutor Contributing
A Nested Volume Manager
Most third party Macintosh hard disk suppliers provide mount manager
applications that allow you to partition their disks into several logical volumes, all
sharing the same storage medium. These schemes were implemented primarily as work
arounds for several limitations in the original Macintosh File System (MFS). For
large volumes, MFS suffers from slow file directory searches and poor volume space
management. Apple's solution to these problems is the new Hierarchical File System
(HFS), introduced in the Fall 1985 on its own 20 megabyte hard disk HD20 product,
and again in January 1986 on its 800k 3.5" disk drive in the Macintosh Plus.
Since HFS provides an better mechanism for handling large storage devices,
Apple saw no need to implement a volume partitioning scheme on its HD20. The HD20
is shipped pre-formatted as a single large volume. Other suppliers have done the
same, such as SuperMac Technology for their DataFrame 20 megabyte external SCSI
hard disk.
In this month's article, I show you how you can partition your HD20 or other
third party HFS hard disk into independent, variable sized nested volumes. Each of
these volumes is built by creating a host file whose contents look like a properly
formatted MFS or HFS volume. Once the host file is created and properly initialized,
its nested volume is available on the Finder's desktop and in application's open and save
MiniFinder dialogs just like any other ordinary volume.
Why Use Nested Volumes?
I've found the "nested volume in a host file" capability to be useful in a variety of
ways. You can port MFS-only systems, such as Apple's MDS and third party
development systems, onto an HD20 or other HFS disk simply by creating one or more
MFS nested volumes. (Of course, as development system suppliers release HFS
upgrades, this capability will be less useful. As of March 1986, the only shipping HFS
C language systems I'm aware of are Consulair Mac C and Megamax C). Another
potential use is as a simple volume level security system. You might want to associated
a password with each nested volume, in a manner similar to that done by General
Computer on its Hyperdrive product. A final use is purely academic. The manager
provides a good excuse for an inside look at the organization of the Macintosh File and
Disk Driver operating system components. An understanding of these components is
e specially useful now with the new opportunities available in the Macintosh Plus -
SCSI based peripheral market.
File System and Disk Driver Organization
The Macintosh File System is the part of the Operating System that manages the
communication between an application and files on a block oriented storage medium,
such as a hard disk drive. Each storage medium is formatted into one or more volumes,
each of which contains some descriptive information along with a set of files.
Fig. 1: File System and Disk Driver Organization
Before an application can access the files on a volume, the volume must be
mounted. The File System mounts a volume by reading the volume's descriptive
information into memory and using it to build a new volume control block, which is
inserted into the volume control block queue. The File System performs this mounting
process automatically both at boot time and whenever a 3.5" disk is inserted into a
drive. Usually, non-ejectable volumes, such as those on hard disks, are always
mounted. However, an application may direct the File System to mount or unmount any
volume at any time. The third party mount managers mentioned above perform just
these functions.
In order to mount a volume, as well as to access its files, the File System must
first determine which storage medium contains the volume. (Typically, the medium is
a disk drive, but it may be a section of memory allocated to a RAM disk.) Furthermore,
once the medium is located, the File System must be able to read and write any
accessible block on that medium. The File System does not do these things itself, instead
it relies on the drive queue and on a disk driver. The drive queue contains one drive
queue element for each available storage medium. Each drive queue element contains,
among other things, a drive number uniquely identifying the medium and a disk driver
number uniquely identifying the disk driver program that controls that medium. The
drive number of the drive containing a volume is also placed in the volume's control
block. Hence, given a reference to a volume, the File System can easily find its
corresponding drive queue element and the identity of its disk driver.
Once the File Manager has determined the drive number and the controlling disk
driver of the medium containing the volume, it calls the disk driver to transfer blocks
of 512 characters to and from the device. The disk driver takes the positioning
information and data from the File System and converts them into commands for the
disk drive's hardware controller and interface electronics. Any resulting data and
completion codes are returned to the File System when the transfer operation
completes. The biggest advantage of this scheme is that new RAM based disk drivers can
be added to the system to support new storage media without any modification to the
fixed, ROM based File System.
Fig. 2: Creating an 800k HFS Nested Volume Named Editor
Normally, the drive queue contains one element for each physical storage
medium connected to the Macintosh, including the internal and external drives, RAM
disks, and hard disks, etc. In the case where several logical volumes share the same
storage medium, convention dictates that one element be placed in the drive queue for
each logical volume. This convention guarentees that each mounted volume has
associated with it a unqiue drive number. Although the drive queue elements of these
volumes have differing drive numbers, they all share the same disk driver number.
Hence, given a drive number of a particular mounted volume, a disk driver should be
able to determine both the identity of the storage medium containing the volume, as well
as the location of the volume's data within that medium. In the case of a volume nested
within a host file, this information consists of the drive number of the volume that
contains the nested volume's host file, as well as the location within the volume of the
host file's contents.
Nested Volumes
Two pieces of software are required to implement nested volumes:
• A mount manager, and
• A disk driver.
The mount manager, which I implemented as a desk accessory named Nest,
presents a user interface that allows you to create, mount and unmount nested volumes.
The desk accessory is responsible for establishing the necessary drive queue elements
and other data structures that allow File System and the disk driver to correctly locate
and transfer information to and from the volume's host file. For those of you familiar
with General Computer's Hyperdrive product, Nest incorporates the functions of both
their Drawers desk accessory and their Manager application.
The second component of the system, the disk driver .Nest, is responsible for
redirecting and translating the File System's block level read and write requests to and
from the nested volume into reads and writes to and from the contents of the volume's
host file. The driver is shared by all of the mounted nested volumes, and uses
information defined by the desk accessory to associate each volume with the contents of
its host file.
When creating a volume, the desk accessory displays a standard save dialog
allowing you to name the volume, as well as specify its size and whether it should be
initialized as an MFS or HFS volume. In the example below, I show the creation of the
800K HFS nested volume Editor. The host file containing the new volume, which is also
named Editor, will be saved in the Nest folder of the volume DataFrame. (Normally, the
name of a nested volume is the same as the name of its host file, however, you may later
change the name of either one in the Finder with no ill effects other than your own
confusion.) I implemented the dialog's extra buttons and text items in the standard way
using the standard file packages documented hooks.
The desk accessory creates the nested volume's host file by calling the routine
newnest. Its arguments are the file name and volume reference number returned by the
standard file save dialog, along with the desired size of the volume in blocks of 512
characters. Newnest first uses the File Manager's routine create to create the file, and
then the new HFS routine alloccontig to allocate the desired number of blocks in one
contiguous area. Alloccontig is identical to the original File System routine allocate,
except that if there isn't enough contiguous, empty space on the volume to satisfy the
allocation request, alloccontig will do nothing and will return dskfulerr as its function
result. By allocating the space in one contiguous area, we greatly simplify the
implementation of the disk driver.
If the allocation succeeds, the routine seteof is called to set the file's logical
end-of-file equal to the desired size of the volume. Finally, newnest closes the file and
flushes the volume on which the file resides. If the allocation request cannot be
satisfied, newnest deletes the file before returning.
int newnest(fname, vrefnum, blocks)
char *fname;
int vrefnum;
int blocks;
{
long count;
int frefnum;
int result;
/* create and open file */
fsdelete(fname, vrefnum);
create(fname, vrefnum, NESTCREATOR, NESTTYPE);
fsopen(fname, vrefnum, &frefnum);
/* allocate contiguous area, save result */
count = (long) blocks * 512;
result = alloccontig(frefnum, &count);
/* set logical end-of-file */
count = (long) blocks * 512;
seteof(frefnum, count);
/* close, flush, delete if allocation failed, and */
/* return result */
fsclose(frefnum);
if (result)
fsdelete(fname, vrefnum);
flushvol(0l, vrefnum);
return result;
}
When mounting a volume, the desk accessory displays a standard open dialog
allowing you to select one of the previously created host files. In the example below, I
show the selection of the nested volume contained in the host file Editor from the Nest
folder of DataFrame.