SPC-3 Prevent/Allow Media Removal and media changers

RRose at exabyte.com RRose at exabyte.com
Thu Sep 18 16:45:22 PDT 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* RRose at exabyte.com
*
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C37E3E.ED0955F0
Content-Type: text/plain;
	charset="iso-8859-1"

Issues came up here with regards to SPC-3's table 92 describing the
effects of "Prevent Allow Medium Removal" for  Independent and Attached
Media Changers.  Looking things over, I tend to agree that the table is
either confusing or not entirely correct.  This problem dates back to
the original SPC doc.


Assumption: 
----------- 

I suspect that the intent of expanding the PREVENT field to two bits was
to add a bit allowing Attached Media Changers to control unloading of
the embedded device (e.g. tape drive, dvd).  This solves the problem of
not being able to send a separate cdb to an embedded device residing at
the same LUN as the media changer.

I also suspect that the intent was to leave all other devices (including
Independent Media Changers) working as before, since those devices
didn't have this problem with Prevent Allow Media Removal.


Problem: 
-------- 

SPC-3 Rev 15 Table 92's "data transport element" equates to the
underlying device behind SMC's "Data Transfer Element".  With this
interpretation, table 92 works for any device; except, Independent Media
Changers.  It can't work properly for Independent Media Changers,
because they are only allowed to use PREVENT values of 01b and 00b.

As written in SPC/SPC-1/SPC-2, the values of 00b and 01b control
unloading of the drive; whereas, the desire is to control locking of the
doors and import/export elements as occurred in SCSI-2.  Current backup
applications send separate Prevent Allow Media Removals with
PREVENT==01b to the Independent Media Changer (to lock the doors) and
the drive (to prevent unloads), so retaining this behavior is highly
desirable.  (Backup application vendors please feel free to correct me
on this.)

As is, a strict reading of the SPC-x doc's doesn't allow any way of
disabling Import/Export and locking doors on Independent Media Changers.
This can't be what was intended.


Possible solutions: 
------------------- 

My preferred solution is to make table 92 apply only to Attached Media
Changers, then use a separate table to describe the effect of 00b and
01b for Independent Media Changers and all other removable media
devices.  This second table would only refer to "the target" and avoid
references to "data transport" or "data transfer" or anything else
limiting the type of device beyond support of removable media.  This
solution would also restore backwards compatibility with SCSI-2.

Another possibility would be to reverse the meaning of bit 1 and bit 0
on Attached Media Changers, so that bit 0 controls the Import/Export
Elements and door locks on both types of libraries.  Bit 1 would then
only apply to Attached Media changers and would control unloading the
embedded device (i.e. Data Transfer Element).  This solution, of course,
is impractical if anybody ever implemented an Attached Media Changer
according to any of the SCSI-3 SPC-x documents.  (I don't know this
answer.  The backup application vendors are probably the best source of
whether anything like this exists.  Unfortunately, the likelihood of
conflict is moderate-to-high, because the expansion of the PREVENT field
serves only to support Attached Media Changers.)

The last possibility that comes to mind is to change Independent Media
Changer's to use PREVENT values of 10b and 00b.  I would view this as
the least desirable, since it would definitely break every Independent
Media Changer and backup application that I've evaluated.  It also makes
SCSI-3 incompatible with SCSI-2 in ways very likely to confuse the
host's applications.


-roger rose 
 Exabyte Corp 

 new email: rrose at exabyte.com 


------_=_NextPart_001_01C37E3E.ED0955F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

 SPC-3 Prevent/Allow Media Removal and media changers Issues came up here with regards to SPC-3's table 92 = describing the effects of ;Prevent Allow Medium Removal; = for  Independent and Attached Media Changers.  Looking things = over, I tend to agree that the table is either confusing or not = entirely correct.  This problem dates back to the original SPC = doc. 
Assumption: 
----------- I suspect that the intent of expanding the PREVENT = field to two bits was to add a bit allowing Attached Media Changers to = control unloading of the embedded device (e.g. tape drive, dvd).  = This solves the problem of not being able to send a separate cdb to an = embedded device residing at the same LUN as the media = changer. I also suspect that the intent was to leave all other = devices (including Independent Media Changers) working as before, since = those devices didn't have this problem with Prevent Allow Media = Removal. 
Problem: 
-------- SPC-3 Rev 15 Table 92's ;data transport = element; equates to the underlying device behind SMC's ;Data = Transfer Element;.  With this interpretation, table 92 works = for any device; except, Independent Media Changers.  It can't work = properly for Independent Media Changers, because they are only allowed = to use PREVENT values of 01b and 00b. As written in SPC/SPC-1/SPC-2, the values of 00b and = 01b control unloading of the drive; whereas, the desire is to control = locking of the doors and import/export elements as occurred in = SCSI-2.  Current backup applications send separate Prevent Allow = Media Removals with PREVENT=3D=3D01b to the Independent Media Changer = (to lock the doors) and the drive (to prevent unloads), so retaining = this behavior is highly desirable.  (Backup application vendors = please feel free to correct me on this.) As is, a strict reading of the SPC-x doc's doesn't = allow any way of disabling Import/Export and locking doors on = Independent Media Changers.  This can't be what was = intended. 
Possible solutions: 
------------------- My preferred solution is to make table 92 apply only = to Attached Media Changers, then use a separate table to describe the = effect of 00b and 01b for Independent Media Changers and all other = removable media devices.  This second table would only refer to = ;the target; and avoid references to ;data = transport; or ;data transfer; or anything else limiting = the type of device beyond support of removable media.  This = solution would also restore backwards compatibility with = SCSI-2. Another possibility would be to reverse the meaning = of bit 1 and bit 0 on Attached Media Changers, so that bit 0 controls = the Import/Export Elements and door locks on both types of = libraries.  Bit 1 would then only apply to Attached Media changers = and would control unloading the embedded device (i.e. Data Transfer = Element).  This solution, of course, is impractical if anybody = ever implemented an Attached Media Changer according to any of the = SCSI-3 SPC-x documents.  (I don't know this answer.  The = backup application vendors are probably the best source of whether = anything like this exists.  Unfortunately, the likelihood of = conflict is moderate-to-high, because the expansion of the PREVENT = field serves only to support Attached Media Changers.) The last possibility that comes to mind is to change = Independent Media Changer's to use PREVENT values of 10b and 00b.  = I would view this as the least desirable, since it would definitely = break every Independent Media Changer and backup application that I've = evaluated.  It also makes SCSI-3 incompatible with SCSI-2 in ways = very likely to confuse the host's applications. 
-roger rose 
 Exabyte Corp  new email: rrose at exabyte.com 
------_=_NextPart_001_01C37E3E.ED0955F0--




More information about the T10 mailing list