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

Ralph O. Weber roweber at IEEE.org
Thu Feb 24 10:48:02 PST 2005


* 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





More information about the T10 mailing list