MMC4r03 mismatch in PREVENT/ALLOW MEDIUM REMOVAL command

Elliott, Robert (Server Storage) elliott at hp.com
Mon Sep 13 22:25:01 PDT 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <elliott at hp.com>
*
(back to the original question)

I think it is possible and may be a better approach to have SPC-3 adopt
the MMC-4 changes instead.

The key difference seems to be the meaning of byte 4 bit 1.
In SPC-3, it's part of a 2-bit PREVENT field:
Bit 1 set to 0 means that medium removal is allowed for an attached
medium changer; and
Bit 1 set to 1 means it is prohibited for an attached medium changer.
The value of 1 is only supported if the RMB bit and the MCHNGR bit are
both set to 1 in standard INQUIRY data.

Bit 0 controls the prevent state.

In MMC-4, the bits are called PERSISTENT and PREVENT:
Bit 1 set to 0 means nothing special.
    Bit 0 is compatible with SPC-3 and controls the prevent state.

Bit 1 set to 1 changes the meaning of bit 0 for this command:
    Bit 0 set to 0 means clear persistent prevent state
    Bit 0 set to 1 means set persistent prevent state
This is different from SPC-3.

However, MMC-4 does not support attached media changers; it requires
that MCHNGR be set to 0.  The SPC-3 meaning cannot apply to MMC-4.  

Non-MMC-4 devices with MCHNGR set to 0 are supposed to return CHECK
CONDITION/ILLEGAL REQUEST/INVALID FIELD IN CDB if they see bit 1 set to
1.

Therefore, SPC-3 could incorporate MMC-4's definition of a persistent
prevent state without breaking non-MMC-4 software or devices.

The combinations of bit 1/bit 0 would be:
00 allow for device (non-persistent)
01 prevent for device (non-persistent)
10 if MCHNGR=0, persistent allow for device 
10 if MCHNGR=1, allow for device and prevent for attached media changer
11 if MCHNGR=0, persistent prevent for device
11 if MCHNGR=1, prevent for device and attached media changer

MMC-4 devices: work as currently defined in MMC-4 since they don't have
MCHNGR=1
Non MMC-4 devices with media changers: work as currently defined in
SPC-3
Non MMC-4 devices without media changers: for 00 and 01, work as
currently defined in MMC-4.  For 10 and 11, return CHECK CONDITION (as
they do now).

---
Rob Elliott, HP Server Storage
elliott at hp.com 

> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf 
> Of Bill McFerrin
> Sent: Tuesday, September 14, 2004 12:04 AM
> To: T10 Reflector; Henry Gabryjelski
> Subject: RE: MMC4r03 mismatch in PREVENT/ALLOW MEDIUM REMOVAL command
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Bill McFerrin" <billmc at tstar.net>
> *
> Henry,
> Table 328 notes that "prevent state" and "persistent prevent 
> state" are
> entered differently and indeed are different.  Sub-clause 
> 6.18.3.2 is titled
> "Persistent Prevent State" and discusses that state.  
> Sub-clause 6.18.3.3 is
> titled "prevent state" and discusses that state.
> 
> The statement "This command affects the actions of the START/STOP UNIT
> command (6.45) and other mechanisms
> (e.g. manual ejection / media removal systems)." is found in 6.18.3.3
> because it applies only to prevent state, but the statement 
> is not in found
> in 6.18.3.2 because it does not apply to presistent prevent state.
> 
> By placing the descriptions in separate sub-clauses, I was 
> hoping to avoid
> the reader confusion that we had with MF.  Alas, I have 
> failed with some
> readers.  Perhaps an additional sub-clause titled "Allow 
> State" would be
> helpful.  Do you have any  suggestions?
> 
> Now, with respect to SPC-3.  The SPC-3 and MMC-4 definitions of byte 4
> values do not match except when the Persistent Prevent state 
> is cleared and
> the bit 1 of byte 4 is zero.  SPC-3 does not define 
> "persistent prevent
> state", so, relative to SPC-3, we cannot determine if the 
> drive is either in
> it or out of it*.  This is why I am seeking to separate MMC-4 
> PAMR from
> SPC-3 PAMR.
> 
> Regards,
> Bill
> 
> *The belly button on most people is not at all an example of this.
> 
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of Henry
> Gabryjelski
> Sent: Monday, 13 September, 2004 1:54 PM
> To: T10 at t10.org; mtfuji5 at avc-pioneer.com
> Subject: MMC4r03 mismatch in PREVENT/ALLOW MEDIUM REMOVAL command
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Henry Gabryjelski" <henrygab at windows.microsoft.com>
> *
> 
> The text describing the allowed behavior for a drive is confusing
> between the two specifications, Mt. Fuji and MMC.  Looking at recent
> versions of each (MMC4r03 and Mt Fuji 5 v1.50), it is clear 
> that neither
> specification is clear.  The Mt. Fuji document is the more clearly
> written of the two:
> 
> //////////////////////////////////////////////////
> If the Prevent and Persistent bits are both 1, upon receiving this
> command, the logical unit shall disable any eject mechanisms, and all
> media after initial drive spin up shall remain locked in the 
> drive until
> the host issues an eject request, or the Persistent Prevent status is
> reset and the hardware eject mechanism again becomes available.
> ...
> The Persistent Prevent state shall not prevent an eject 
> request from the
> host from succeeding.
> //////////////////////////////////////////////////
> 
> MMC4, however, states the following:
> 
> //////////////////////////////////////////////////
> This command affects the actions of the START/STOP UNIT command (6.45)
> and other mechanisms
> (e.g. manual ejection / media removal systems).
> //////////////////////////////////////////////////
> 
> SPC3 defines the Prevent/Persistent bits very differently, 
> apparently to
> deal with embedded changers.  However, SPC3 (r20a) says the following:
> 
> //////////////////////////////////////////////////
> While a prevention of medium removal condition is in effect, 
> the target
> shall inhibit mechanisms that normally allow removal of the 
> medium by an
> operator.
> //////////////////////////////////////////////////
> 
> It would seem that MMC and SPC are suggesting that an eject 
> request via
> START STOP UNIT should be rejected by the logical unit if either
> Persistent Prevent state or the Prevent state is set.  It also seems
> that Mt. Fuji is suggesting that an eject request via START STOP UNIT
> should be rejected by the logical unit only by the non-persistent
> Prevent state; Another way of seeing this is that the 
> Persistent Prevent
> state should only disable hardware ejection controls.
> 
> First, please let me know I have made any errors in my 
> understanding on
> the above points.  This is a fairly basic area, which affects many
> devices.  Information regarding shipped drive behavior is, of course,
> also valuable (especially if two very different interpretations have
> shipped).
> 
> Presuming the above is correct, it then becomes important to reconcile
> the MMC draft to both shipping products and Mt. Fuji.  There are no
> legacy MMC issues as MMC3 did not define this command (as it 
> was defined
> in SPC).  However, because SPC3 has a different understanding of the
> Persistent bit, we cannot use this as a reference for this command.  I
> would like to suggest that the MMC4 specification adopt the above
> definition for the Persistent Prevent bit (Persistent Prevent state
> affects only eject requests not from the host, such as hardware based
> eject requests(*)).
> 
> As always, your consideration and thoughts on these matters is
> appreciated.
> 
> Sincerely,
> 
> Henry Gabryjelski
> Software Design Engineer
> Microsoft Corporation
> 
> (*) The eject button on the front panel of most drives would 
> be a clear
> example of this.
> 
> -----Original Message-----
> From: owner-mtfuji5 at avc-pioneer.com
> [mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of Henry Gabryjelski
> Sent: Tuesday, September 07, 2004 12:25 PM
> To: T10 at t10.org
> Cc: mtfuji5 at avc-pioneer.com
> Subject: Missing IDs for public DCBs?
> 
> 
> The MMC4r03 specification describes the format of a couple of 
> the DVD+RW
> Disc Control Blocks.  In particular, the Write Inhibit DCB is 
> described
> in section 16.27.2.19.2 on page 340, and the Session DCB is 
> described in
> section 16.27.2.19.3 on page 341.  However, it seems that the 
> identifier
> required to retrieve these DCBs (placed in the "Address" field of the
> CDB) is missing from the specification.
> 
> Can this ommision please be fixed for the next release of the 
> MMC draft
> specification?  Also, if possible, please post these missing values in
> the response (so we needn't wait for the next draft).
> 
> Thanks,
> .
> 
> 
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
*
* 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