de facto obsolete sbc-2 ops

Elliott, Robert Robert.Elliott at
Tue Feb 19 11:51:45 PST 2002

* From the T10 Reflector (t10 at, posted by:
* "Elliott, Robert" <Robert.Elliott at>
> -----Original Message-----
> From: Pat LaVarre [mailto:LAVARRE at]
> Sent: Tuesday, February 19, 2002 10:52 AM
> To: t10 at
> Subject: de facto obsolete sbc-2 ops
> Q1) Do sbc-2 folk hang out here at <t10 at>?
> > The following operation codes
> > are vendor-specific: ... 23h ...
> Q2) I wish.  Has the time come to acknowledge Microsoft's de 
> facto definition of this op?  Can we make x23 "obsolete" 
> rather than "vendor-specific"?

The usual rule is once vendor-specific, always vendor-specific.  

MMC3 defines 23h as "READ FORMAT CAPACITIES". Is it being used on block
devices too? SCSI-2, SBC-1, and SBC-2 all mark it as vendor-specific for
block devices. 

> > ...
> Q3) Can we obsolete x8B?  On the theory that for some people 
> this will be the Seek op for 64-bit Lba's?

16-bit opcodes are a rare commodity; we don't want to discard them just
because the lower bits match some other opcode's lower bits (SEEK(6) at
0Bh and SEEK(10) at 2Bh).

> Thanks in advance.    Pat LaVarre
> P.S.
> > 5.1.43 XDWRITEREAD (32) command
> > This command is only available
> > on transport protocols supporting bidirectional commands.
> Fun, thank you.  I had heard rumour of devices moving out 
> more than the 16 byte Cdb length limit of Atapi/Usb etc. and 
> I had heard rumours of commands that move data both in & out, 
> but this is very concrete.

You may want to peruse the OSD command set, which has lots of long CDBs
and discusses using bidirectional for its CREATE command.

Rob Elliott, Compaq Server Storage
Robert.Elliott at

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

More information about the T10 mailing list