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

Kevin D Butt kdbutt at us.ibm.com
Fri Feb 25 17:45:00 PST 2005


* From the T10 Reflector (t10 at t10.org), posted by:
* Kevin D Butt <kdbutt at us.ibm.com>
*
This is a multipart message in MIME format.
--=_alternative 00099BD207256FB4_=
Content-Type: text/plain; charset="US-ASCII"


Michael, 

After careful scrutiny, I agree with you.  Also, why does the
description have to be so complicated?   
The lsb should control prevent from addressed LUN when the RMB bit is
one (if zero then it doesn't make sense).   
The msb should control prevent from attached media changer and only be
valid if MCHGR is set to one. 

Regards, 

Kevin D. Butt
Fibre Channel & SCSI Architect, IBM Tape Firmware, 
6TYA, 9000 S. Rita Rd., Tucson, AZ  85744
Tie-line 321; Office: 520-799-5280, Lab: 799-5751, Fax: 799-4138, Email:
kdbutt at us.ibm.com 



"Ralph O. Weber" <roweber at IEEE.org> 
Sent by: owner-t10 at t10.org 


02/24/2005 11:48 AM 

To
t10 at t10.org 

cc

Subject
Re: Confusion with the PREVENT field in the PREVENT ALLOW MEDIUM REMOVAL
command

	





* From the T10 Reflector (t10 at t10.org), posted by:
* "Ralph O. Weber" <roweber at ieee.org>
*
Michael,

Is this important enough to handle as a late letter ballot comment
against SPC-3? If the issue can get sorted out by the March CAP
meeting, then the SPC-3 letter ballot is still open.

.Ralph

Banther, Michael wrote:

> 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.
>  
> 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.
>  
> 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.
>  
> 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.
>  
> 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.
>  
> 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.
>  
> 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.
>  
> 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.
>  
> 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.
>  
> Comments welcome.
>  
> Regards,
> Michael Banther
> Hewlett-Packard Ltd.
> Telephone +44 (117) 312-9503
>  



*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



--=_alternative 00099BD207256FB4_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Michael,</font>
<br>
<br><font size=2 face="sans-serif">After careful scrutiny, I agree with
you. &nbsp;Also, why does the description have to be so complicated? &nbsp;</font>
<br><font size=2 face="sans-serif">The lsb should control prevent from
addressed LUN when the RMB bit is one (if zero then it doesn't make sense).
&nbsp;</font>
<br><font size=2 face="sans-serif">The msb should control prevent from
attached media changer and only be valid if MCHGR is set to one.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif"><br>
Kevin D. Butt<br>
Fibre Channel &amp; SCSI Architect, IBM Tape Firmware, <br>
6TYA, 9000 S. Rita Rd., Tucson, AZ &nbsp;85744<br>
Tie-line 321; Office: 520-799-5280, Lab: 799-5751, Fax: 799-4138, Email:
kdbutt at us.ibm.com</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Ralph O. Weber"
<roweber at IEEE.org&gt;</b> </font>
<br><font size=1 face="sans-serif">Sent by: owner-t10 at t10.org</font>
<p><font size=1 face="sans-serif">02/24/2005 11:48 AM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">t10 at t10.org</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Re: Confusion with the PREVENT
field in the PREVENT ALLOW MEDIUM REMOVAL command</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>* From the T10 Reflector (t10 at t10.org), posted by:<br>
* "Ralph O. Weber" <roweber at ieee.org&gt;<br>
*<br>
Michael,<br>
<br>
Is this important enough to handle as a late letter ballot comment<br>
against SPC-3? If the issue can get sorted out by the March CAP<br>
meeting, then the SPC-3 letter ballot is still open.<br>
<br>
.Ralph<br>
<br>
Banther, Michael wrote:<br>
<br>
> We're running into some problems correctly interpreting SMC-2 and
<br>
> SPC-2/3 when implementing a local SMC device server as specified in
ADC.<br>
> &nbsp;<br>
> SMC2r07 includes PREVENT ALLOW MEDIUM REMOVAL as an optional command
<br>
> for independent media changers in Table 3 - Commands For Independent
<br>
> Media Changers. &nbsp;It references SPC-2 for the definition of the
command.<br>
> &nbsp;<br>
> SSC2r09 includes PREVENT ALLOW MEDIUM REMOVAL as an optional command
<br>
> in Table 11 - Explicit Address Command Set For Sequential-Access <br>
> Devices and in Table 18 - Implicit Address Command Set for <br>
> Sequential-Access Devices. &nbsp;Both of these tables reference SPC-3
for <br>
> the definition of the command.<br>
> &nbsp;<br>
> SPC3r21d, Table 119 - PREVENT Field discusses the effect of the values
<br>
> in terms of data transport elements and attached medium changer <br>
> elements. &nbsp;It includes a table note that the field values 10b
and 11b <br>
> are only valid when the INQUIRY bits RMB and MCHNGR equal 1b (by the
<br>
> way, the note has become garbled). &nbsp;SPC2r20, Table 78 - PREVENT
ALLOW <br>
> MEDIUM REMOVAL PREVENT Field contains very similar text. &nbsp;However
it <br>
> includes the restriction on field values 10b and 11b in text just
<br>
> below the table.<br>
> &nbsp;<br>
> SMC2r07, 5.2 Attached Media Changer makes it pretty clear that an
<br>
> attached media changer sets MCHNGR to 1b. &nbsp;Although SMC-2 is
silent, <br>
> I've always read it to imply that an independent media changer sets
<br>
> MCHNGR to 0b. &nbsp;SPC2r20, 7.3.2 Standard INQUIRY Data and SPC3r21d,
<br>
> 6.4.2 Standard INQUIRY Data include text on the meaning of the MCHNGR
<br>
> bit that supports this interpretation.<br>
> &nbsp;<br>
> Hence I interpret the restriction on PREVENT field values as meaning
<br>
> that a logical unit that does not include an attached media changer
<br>
> shall respond to a PREVENT ALLOW MEDIUM REMOVAL CDB with PREVENT set
<br>
> to either 10b or 11b with CHECK CONDITION status and shall set the
<br>
> sense key to ILLEGAL REQUEST and the additional sense code to INVALID
<br>
> FIELD IN CDB. &nbsp;This behaviour holds for a local SMC logical unit,
in a <br>
> device that implements ADI Bridging, that supports the independent
<br>
> media changer model as much as for any other logical unit.<br>
> &nbsp;<br>
> The problem with this interpretation lies in SPC3r21d, Table 119 and
<br>
> SPC2r20, Table 78. &nbsp;These tables associate the lsb of the PREVENT
<br>
> field with a 'data transport element.' &nbsp;Neither SPC-2 nor SPC-3
define <br>
> this term. &nbsp;SMC2r07 defines a 'data transfer element' as 'the
address <br>
> in media changer element space of a data transfer device.' &nbsp;It
then <br>
> goes on to give examples of data transfer devices as magnetic disk
<br>
> drives, cartridge tape drives, optical disk drives, and CD-ROM <br>
> drives. Some people here interpret 'data transport element' and 'data
<br>
> transfer element' as synonyms.<br>
> &nbsp;<br>
> If a 'data transport element' is a 'data transfer element', then an
<br>
> independent media changer device server that receives a PREVENT ALLOW
<br>
> MEDIA REMOVAL command with PREVENT set to 01b is being told to prevent
<br>
> removal of the medium from some removable media drive, not from the
<br>
> media changer itself. &nbsp;Indeed no method exists for an application
<br>
> client to tell a media changer to prevent the removal of a piece of
<br>
> media from the media changer itself.<br>
> &nbsp;<br>
> I believe that the usage of 'data transport element' in Table 119
of <br>
> SPC3r21d and Table 78 of SPC2r20 is incorrect. &nbsp;The lsb of the
PREVENT <br>
> field is associated with preventing/allowing media removal from the
<br>
> physical device associated with the addressed logical unit. &nbsp;If
<br>
> sufficient consensus exists within the removable media community,
I'll <br>
> prepare a proposal for SPC-4 that addresses this problem.<br>
> &nbsp;<br>
> Comments welcome.<br>
> &nbsp;<br>
> Regards,<br>
> Michael Banther<br>
> Hewlett-Packard Ltd.<br>
> Telephone +44 (117) 312-9503<br>
> &nbsp;<br>
<br>
<br>
<br>
*<br>
* For T10 Reflector information, send a message with<br>
* 'info t10' (no quotes) in the message body to majordomo at t10.org<br>
</tt></font>
<br>
--=_alternative 00099BD207256FB4_=--





More information about the T10 mailing list