[t10] SPC of MMC obsolete or different

Pat LaVarre LAVARRE at iomega.com
Thu Jan 9 17:06:14 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
> From: Elliott, Robert (Server Storage) [mailto:Elliott at hp.com] 
> I notice that mmc4r01f includes sections defining
> commands that have a home in other standards
> (especially SPC-3 ...
 
Me, offline, I heard that the SPC in MMC is not merely obsolete, but substantively different in small details, when compared with the ANSI idea of SPC.
 
Untrue?
 
If true, this would be a pernicious binary incompatibility analogous to the SFF idea of ModeSense, in which DBD zeroed meant no block descriptor, in contrast with the ANSI idea of ModeSense, in which DBD zeroed meant yes block descriptor.  Also analogous to SFF making ModeSense10 required, while leaving ModeSense6 unmentioned, in contrast with ANSI requiring ModeSense6, but leaving ModeSense10 optional.
 
I've also heard rumours of an SPC vs. RBC conflict over ModeSense, dunno if those are true either.
 
Curiously yours in essentially irredeemable ignorance, Pat LaVarre

	-----Original Message----- 
	From: Elliott, Robert (Server Storage) [mailto:Elliott at hp.com] 
	Sent: Thu 1/9/2003 4:25 PM 
	To: Bmcferrin at aol.com; t10 at t10.org 
	Cc: 
	Subject: RE: MMC WG Meeting Announcement: 15 January 2003
	
	

	* From the T10 Reflector (t10 at t10.org), posted by:
	* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
	*
	 >  7.0 New Business
	 >  Review the MMC-4 draft revision 1f.
	
	I notice that mmc4r01f includes sections defining commands that have a
	home in other standards (especially SPC-3 commands like INQUIRY, REQUEST
	SENSE, TEST UNIT READY, MODE SENSE, MODE SELECT, READ BUFFER, and WRITE
	BUFFER); these were not in mmc3.  I think this is a mistake.  If a
	correction is made in SPC-3, it's not going to be automatically tracked
	in MMC-4, and vice-versa.
	
	For example, in the INQUIRY command, SPC-3 recently grew the ALLOCATION
	LENGTH field to 2 bytes from 1 byte; MMC-4's version still only shows
	one byte.  SPC-3 is obsoleting references to asynchronous event
	reporting, but MMC-4 still references those bits.  SPC-2 defined
	"version descriptors" in bytes 56-95, while MMC-4 shows them as
	reserved. 
	
	If MMC-4 needs to "profile" those commands, I think it can so without
	appearing to redefine any of the fields.  Don't show the CDB format;
	just include a table with the fields of interest and provide comments on
	the MMC-4 requirements for those fields.  For example, INQUIRY could
	have a table listing:
	PERIPHERAL DEVICE TYPE  00101b
	PERIPHERAL QUALIFIER    000b
	RMB                     1
	but leave it up to SPC-3 to define what those fields mean.  Don't even
	mention fields like BQue and CmdQue where MMC-4 devices are free to
	implement anything they want.
	
	Some of the fields marked as "shall be 0" in the current draft seem a
	bit overreaching.  Why does MMC-4 need to prohibit an access control
	coordinator, asymmetric logical unit access, or enclosure services from
	coexisting in an MMC-4 logical unit? 
	
	--
	Rob Elliott, elliott at hp.com
	Hewlett-Packard Industry Standard Server Storage Advanced Technology
	https://ecardfile.com/id/RobElliott
	
	
	*
	* 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