Confusion with the PREVENT field in the PREVENT ALLOW MEDIUM REMOVAL command

Banther, Michael michael.banther at hp.com
Thu Feb 24 06:33:19 PST 2005


* From the T10 Reflector (t10 at t10.org), posted by:
* "Banther, Michael" <michael.banther at hp.com>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C51A7D.C9198525
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C51A7D.C9198525"


------_=_NextPart_002_01C51A7D.C9198525
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We're running into some problems correctly interpreting SMC-2 and
SPC-2/3 when implementing a local SMC device server as specified in =
ADC.
=20
SMC2r07 includes PREVENT ALLOW MEDIUM REMOVAL as an optional command =
for
independent media changers in Table 3 - Commands For Independent Media
Changers.  It references SPC-2 for the definition of the command.
=20
SSC2r09 includes PREVENT ALLOW MEDIUM REMOVAL as an optional command in
Table 11 - Explicit Address Command Set For Sequential-Access Devices
and in Table 18 - Implicit Address Command Set for Sequential-Access
Devices.  Both of these tables reference SPC-3 for the definition of =
the
command.
=20
SPC3r21d, Table 119 - PREVENT Field discusses the effect of the values
in terms of data transport elements and attached medium changer
elements.  It includes a table note that the field values 10b and 11b
are only valid when the INQUIRY bits RMB and MCHNGR equal 1b (by the
way, the note has become garbled).  SPC2r20, Table 78 - PREVENT ALLOW
MEDIUM REMOVAL PREVENT Field contains very similar text.  However it
includes the restriction on field values 10b and 11b in text just below
the table.
=20
SMC2r07, 5.2 Attached Media Changer makes it pretty clear that an
attached media changer sets MCHNGR to 1b.  Although SMC-2 is silent,
I've always read it to imply that an independent media changer sets
MCHNGR to 0b.  SPC2r20, 7.3.2 Standard INQUIRY Data and SPC3r21d, 6.4.2
Standard INQUIRY Data include text on the meaning of the MCHNGR bit =
that
supports this interpretation.
=20
Hence I interpret the restriction on PREVENT field values as meaning
that a logical unit that does not include an attached media changer
shall respond to a PREVENT ALLOW MEDIUM REMOVAL CDB with PREVENT set to
either 10b or 11b with CHECK CONDITION status and shall set the sense
key to ILLEGAL REQUEST and the additional sense code to INVALID FIELD =
IN
CDB.  This behaviour holds for a local SMC logical unit, in a device
that implements ADI Bridging, that supports the independent media
changer model as much as for any other logical unit.
=20
The problem with this interpretation lies in SPC3r21d, Table 119 and
SPC2r20, Table 78.  These tables associate the lsb of the PREVENT field
with a 'data transport element.'  Neither SPC-2 nor SPC-3 define this
term.  SMC2r07 defines a 'data transfer element' as 'the address in
media changer element space of a data transfer device.'  It then goes =
on
to give examples of data transfer devices as magnetic disk drives,
cartridge tape drives, optical disk drives, and CD-ROM drives. Some
people here interpret 'data transport element' and 'data transfer
element' as synonyms.
=20
If a 'data transport element' is a 'data transfer element', then an
independent media changer device server that receives a PREVENT ALLOW
MEDIA REMOVAL command with PREVENT set to 01b is being told to prevent
removal of the medium from some removable media drive, not from the
media changer itself.  Indeed no method exists for an application =
client
to tell a media changer to prevent the removal of a piece of media from
the media changer itself.
=20
I believe that the usage of 'data transport element' in Table 119 of
SPC3r21d and Table 78 of SPC2r20 is incorrect.  The lsb of the PREVENT
field is associated with preventing/allowing media removal from the
physical device associated with the addressed logical unit.  If
sufficient consensus exists within the removable media community, I'll
prepare a proposal for SPC-4 that addresses this problem.
=20
Comments welcome.
=20
Regards,
Michael Banther
Hewlett-Packard Ltd.
Telephone +44 (117) 312-9503
=20

------_=_NextPart_002_01C51A7D.C9198525
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

 We're = running into=20 some problems correctly interpreting SMC-2 and SPC-2/3 when = implementing a local=20 SMC device server as specified in ADC.
  
 SMC2r07 includes=20 PREVENT ALLOW MEDIUM REMOVAL as an optional command for independent = media=20 changers in Table 3 - Commands For Independent Media Changers.  It = references SPC-2 for the definition of the command.
  
 SSC2r09 includes=20 PREVENT ALLOW MEDIUM REMOVAL as an optional command in Table 11 - = Explicit=20 Address Command Set For Sequential-Access Devices and in Table 18 = -=20 Implicit Address Command Set for Sequential-Access Devices.  Both = of these=20 tables reference SPC-3 for the definition of the = command.
  
 SPC3r21d, Table 119=20 - PREVENT Field discusses the effect of the = values in terms=20 of data transport elements and attached medium changer elements.  = It=20 includes a table note that the field values 10b and 11b are only valid = when the=20 INQUIRY bits RMB and MCHNGR = equal 1b (by=20 the way, the note has become garbled).  SPC2r20, Table 78 - = PREVENT=20 ALLOW MEDIUM REMOVAL PREVENT Field contains very = similar=20 text.  However it includes the restriction on field values 10b and = 11b in=20 text just below the table.
  
 SMC2r07, 5.2=20 Attached Media Changer makes it pretty clear that an attached media = changer sets=20 MCHNGR to 1b.  Although SMC-2 is silent, = I've always=20 read it to imply that an independent media changer sets MCHNGR to 0b.  SPC2r20, 7.3.2 Standard INQUIRY Data = and=20 SPC3r21d, 6.4.2 Standard INQUIRY Data include text on the meaning of = the MCHNGR bit that supports this = interpretation.
  
 Hence = I interpret=20 the restriction on PREVENT field values as = meaning that a=20 logical unit that does not include an attached media changer shall = respond to a=20 PREVENT ALLOW MEDIUM REMOVAL CDB with PREVENT set = to either=20 10b or 11b with CHECK CONDITION status and shall set the sense key to = ILLEGAL=20 REQUEST and the additional sense code to INVALID FIELD IN CDB.  = This=20 behaviour holds for a local SMC logical unit, in a device that = implements=20 ADI Bridging, that supports the independent media changer model as much = as for=20 any other logical unit.
  
 The = problem with=20 this interpretation lies in SPC3r21d, Table 119 and SPC2r20, Table = 78. =20 These tables associate the lsb of the PREVENT field with a 'data = transport=20 element.'  Neither SPC-2 nor SPC-3 define this term.  SMC2r07 = defines=20 a 'data transfer element' as 'the address in media changer element = space of a=20 data transfer device.'  It then goes on to give examples of data = transfer=20 devices as magnetic disk drives, cartridge tape drives, = optical disk=20 drives, and CD-ROM drives. Some people here interpret 'data = transport=20 element' and 'data transfer element' as = synonyms.
  
 If a = 'data transport=20 element' is a 'data transfer element', then an independent media = changer device=20 server that receives a PREVENT ALLOW MEDIA REMOVAL command with PREVENT set to 01b is being told to prevent removal of = the medium=20 from some removable media drive, not from the media changer = itself.  Indeed=20 no method exists for an application client to tell a media changer to = prevent=20 the removal of a piece of media from the media changer=20 itself.
  
 I = believe that the=20 usage of 'data transport element' in Table 119 of SPC3r21d and Table 78 = of=20 SPC2r20 is incorrect.  The lsb of the PREVENT field is associated = with=20 preventing/allowing media removal from the physical device associated = with the=20 addressed logical unit.  If sufficient consensus exists within the = removable media community, I'll prepare a proposal for SPC-4 that = addresses this=20 problem.
  
 Comments=20 welcome.
  
 Regards,

 Michael = Banther
 Hewlett-Packard = Ltd.
 Telephone +44 (117)=20 312-9503
  


------_=_NextPart_002_01C51A7D.C9198525--

------_=_NextPart_001_01C51A7D.C9198525
Content-Type: text/x-vcard;
	name="BANTHER,MICHAEL (HP-UnitedKingdom,ex2).vcf"
Content-Transfer-Encoding: base64
Content-Description: BANTHER,MICHAEL (HP-UnitedKingdom,ex2).vcf
Content-Disposition: attachment;
	filename="BANTHER,MICHAEL (HP-UnitedKingdom,ex2).vcf"

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkJBTlRIRVI7TUlDSEFFTA0KRk46QkFOVEhFUixN
SUNIQUVMIChIUC1Vbml0ZWRLaW5nZG9tLGV4MikNCk9SRzpIUC1Vbml0ZWRLaW5nZG9tLGV4MjtD
NjAwLTUzMDINClRFTDtXT1JLO1ZPSUNFOjMxMi05NTAzDQpURUw7V09SSztWT0lDRTorNDQgMTE3
IDMxMiA5NTAzDQpBRFI7V09SSzo7TVMgMkIyMjs7QlJJU1RPTCwgR0INCkxBQkVMO1dPUks7RU5D
T0RJTkc9UVVPVEVELVBSSU5UQUJMRTpNUyAyQjIyPTBEPTBBQlJJU1RPTCwgR0INCkVNQUlMO1BS
RUY7SU5URVJORVQ6bWljaGFlbF9iYW50aGVyQGhwLmNvbQ0KUkVWOjIwMDMwNzE3VDA4Mjk0OFoN
CkVORDpWQ0FSRA0K

------_=_NextPart_001_01C51A7D.C9198525--





More information about the T10 mailing list