X3T9.2/87-100


To: John Lohmeyer                                 7/1/87

From: Ralph Schultz

Subject: SCSI Problems with Removable Media (Changers)


In recent meetings of both the plenary and working groups of ANSC X3T9.2, 
there has been considerable discussion concerning the SCSI command set for 
media changers, particularly optical disk changers.  Most of the discussion 
has centered about the concept of extending the logical space of SCSI to 
accommodate the exceptionally large number of sectors which are available 
on an array of optical disks mounted in a changer mechanism.  

There may be a satisfactory method of changing the command block addressing 
scheme to logically access any sector on any disk in the changer.  This 
scheme would intelligently take care of the problem of which disk is 
currently mounted, and exchange the current one for the desired one 
unbeknownst to the user.  Of course, this would only work if the desired 
disk (logical sub-space) is in the changer.

However, this kind of solution does not solve the problem of accessing any 
of the multitude of disks which may be located in the archive area, or 
located remotely in another disk library of another system, on the shelves 
of a long term storage facility, etc.  It may prove helpful if the 
implementation approach examined the present system handling of removable 
media (such as magnetic tape) and extended these system concepts back into 
SCSI.  

A brief description of the work flow and system implementation of removable 
magnetic tape:  Because the media is removable and replaceable, the 
system needs to know what is accessible (mounted) and what needs to be 
mounted in order to be accessible.  The system knows what is mounted by 
reading a (volume) label from the media.  This label can be in many forms 
ranging from multi-character alpha numeric to pure binary number.  The key, 
however, is that the system filing hierarchy also knows of other unmounted 
volumes.  The extent of this knowledge is system dependent, but all systems 
have some knowledge of data which is not currently accessible by the 
system.

Should a volume not be mounted, the operating system sends a message to the 
operator to mount the desired volume, and in some instances, which volume 
to remove.  When the new volume is mounted, the operating system reads the 
label and updates the internal tables.  Note here that references will then 
be made to (logical) records within the volume.  References outside the 
array of mounted volumes will again result in operator messages, because 
the system does not know where to find the inaccessible volumes.  

A good case can be made for extending these concepts into media changers.  
There now exist operating systems which have extended the removable media 
concepts into a subset of 'mounted, but not accessible' volumes.  These 
volumes are the ones in the changer, but not mounted in an actual drive.  
The operating system knows, however, which volumes are in the actual 
drive(s), and if a change is required, will take care of removing the 
'appropriate' volume from a drive and replacing it with the desired one.  
This function is performed on a purely physical level, as the operating 
system tells the changer to 'remove volume X from drive Y' and 'load volume 
Q into drive Y'.  These changer commands are in the same form as sent to 
the operator in the non-automated system.  When the drive is again spun up, 
the label is read, and the system proceeds to access data.  Because the 
operating system is involved with selection of what is to be mounted, where 
it is to be mounted, what is to be removed, the offloading of these 
functions to SCSI intelligent controllers is not really feasible.  

One of the concepts which merit is the concept of virtual drives.  Each of 
the volumes in the changer reside in a virtual drive.  There is at least 
one real drive.  SCSI then permits addressing all the virtual drives, and 
if a volume addressed is not in the real drive(s), an exchange takes place.  
This concept can be extended to address drives outside the changer domain, 
which then result in a "page fault".  Such a fault results in an operator 
message to remove a volume and mount another volume.  Note that the program 
flow is significantly changed from the example above, resulting in 
significant rethinking of the operating systems functioning on the larger 
computing systems which can justify changer devices.  Another significant 
problem is the designation of which volume to remove.  If the system is 
truly virtual, then such a decision would have to be made by the SCSI 
device!  If the problem is to be resolved by the operating system, the 
problem is solved at the purely physical level by the time commands are 
sent to the SCSI device.

As briefly discussed at the Vancouver meeting, SCSI does not really address 
the next layered level.  Until this layer is considered and defined, I 
believe that SCSI can only manage physical operation of changer devices.  
If the arguments stated in this paper are also valid, then I believe that 
X3T9.2 should only address commands which manage the physical 
characteristics of changer devices to the extent that the various vendors 
can agree on a common approach.  The exact model to be chosen also needs 
work, but it will always be a hybrid between logical and physical.  This 
solution is equally applicable to magnetic tape changer devices.  

I hope that this document has provided some basis for constructive 
discussion and resolution.  I recommend that at the July working group 
interested parties convene and attempt to reach agreement on an 
architecture for changer devices.  Only then can agreement be reached on 
command sets.  We have spent too much time in both plenary and working 
group meetings without any progress towards a goal.